genericisation way-point ...

[Havoc Pennington]

On Mon, 2004-04-19 at 09:52, Michael Meeks wrote:
> 
> 	* CORBA defines CORBA_boolean as an unsigned char; this 
> 	  (perhaps) removes some uncertainty wrt. arrays - it seems
> 	  Boolean arrays are of type 'byte' but individually are 'int'
> 

One issue here is varargs; IIRC that's why gboolean ended up as an int,
there were too many funky bugs with it as char. But this discussion was
pre-GTK-1.x so I don't know if I remember.

The arrays are bytes because wasting 4x bandwidth seemed kind of awful.
Ideally we'd do a bit vector I guess, which also eliminates this
problem:

> 	* Also interesting that individual bytes are normalized to 1/0
> 	  but array contents are not - should they be ?

Yes, but it's slow.

I guess my feeling is that for a bool passed in/out of C API,
dbus_bool_t should be used and map to int. But for the wire protocol
bytes should always be used, unless we want to code bit vector stuff.

> 	* I'm not completely sure what the message builders 
> 	  align/unalign stuff is all about - nevertheless it shows no
> 	  signs of stopping working.

The data values have to be aligned with respect to the start of the
message header or message body. The DBusString is always allocated on an
8-byte boundary. Then doubles have to be on 8-byte boundaries from
string start, ints on 4-byte, etc. I think the details of when and where
there's padding are in the spec.

the ALIGN command in message builder lets you build a message with
things aligned, and UNALIGN lets you build a message with them not
aligned. You need the aligned for valid messages and the unaligned for
invalid messages. If a message has broken alignment the parser should
reject it.

> 	* for types; I've switched from 'int' to 'char' since (I'm 
> 	  hoping) to have recursive types specified by a (human 
> 	  readable ) string eventually; is that ok ?

You switched where? They are already ASCII chars:
 
#define DBUS_TYPE_INVALID       ((int) '\0')
#define DBUS_TYPE_NIL           ((int) 'v')
#define DBUS_TYPE_BYTE          ((int) 'y')

I don't really remember why I put the (int) cast there, I'm pretty sure
C always does that automatically anyhow. I'm sure I had some rationale
invented.

The idea of making them ASCII chars with nul termination was to be able
to treat the type signature as a string.

Havoc