Summary: | Empty struct '()' not supported | ||
---|---|---|---|
Product: | dbus | Reporter: | Allison Lortie (desrt) <desrt> |
Component: | core | Assignee: | Havoc Pennington <hp> |
Status: | RESOLVED FIXED | QA Contact: | John (J5) Palmieri <johnp> |
Severity: | normal | ||
Priority: | high | Keywords: | patch |
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | patch to dbus-specification specifically forbidding signature '()' |
Description
Allison Lortie (desrt)
2006-08-23 11:54:42 UTC
first what is triff? second we don't have tuples just structs. They aren't dynamic. A signature of () means it always has to be empty which I don't belive is legal though the spec doesn't say one way or the other. tuples are structs triv is the type of the empty structure (ie: structure containing zero items) triff is the only possible value of that type (sort of like how there is only one possible string of length zero - "") they are both (the type and the value) written as () in languages like haskell. from talking on irc, rob seems to think that the spec actually allows empty tuples (or structs as you say). where structs are introduced in the spec there is never any statement that certain cases (like empty structs are outlawed). this is valid C, btw: struct foo {}; :) This is probably pretty simple to add (may be a matter of deleting code that disallows it, more so than adding code). Question I'd ask is how many existing language bindings would choke on it... you can do this in C maybe but it isn't useful/sensible afaik... I would expect python allows an empty tuple... I don't know what the struct mapping is in Qt or Java bindings. For the variant case, allowing a variant containing DBUS_TYPE_INVALID might be more sensible? i imagine both measures are reasonable in their own ways. just from a logical standpoint -- it seems weird to specifically forbid the case of triv unless you have a specific reason to do so (like it causes certain language bindings to break). zero is just as good of a number as 2 or 3. it should even be possible (albiet odd) to have functions that take zero-tuples as first-order arguments (ie: outside of variants). i can't imagine why anyone would want to do this but it makes sense for purposes of being consistent. allowing the sending of the 'invalid' type in a variant is a bit less logically sound since it's not possible to send this outside of a variant directly on the wire as itself (since, for example, this type is often used to terminate lists of types of arguments). you could never have a function that takes an invalid as an argument. if anything, this should be seen as a workaround. the more i think about this problem it comes down to the fact that dbus has no equiv to G_TYPE_NONE (ie: the 'void' type). the idea of using triv just makes sense since functional programming languages that don't have a void type either (why would a function return void??) use triv to replace void in cases where returning void really *does* make sense (like in a monad). If the D-Bus protocol forbids empty structs (and since the reference implementation of the bus daemon will disconnect you if you send them, the only safe assumption is that it does), the spec should say so. Attaching a patch. Created attachment 11954 [details] [review] patch to dbus-specification specifically forbidding signature '()' Perfect, thanks. (commit at will) This was committed three years ago this week: bf7c65f5218d07734bcc7be373ebc33278806824 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.