Re: adasockets and adatypes

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Not exactly sure I understand what you are describing, but I will say this:
I've used C to read/write data to a stream and usually, I've resorted to
having some function that manually tore the data apart and put it into the
stream - not dissimilar to creating a 'Read or 'Write procedure for some
structure. I've had to do that because C didn't provide a good way for me to
control where the bits and bytes fell within a struct and the minute
something got the least bit unusual, you just couldn't get there with its
lame representation specifications. In simpler cases where I got to define
the message content, you could basically build a struct that was at least
consistent and do some kind of overlay or similar pointer tricks to just get
it as a stream of bytes.

As for endianness and/or some kind of general portability, I've not had to
deal with that in C because the environment was usually self-contained
enough that you could be sure that both ends were doing the same thing.
Those who insist on absolute portability don't have the balls to live in the
real world. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vpu96ehbx.fsf@smaug.pushface.org...
>
> I would have thought the ideal non-automated C way of doing this would
> be to define a wire format that is convenient for manipulating
> endianness (eg, no packing) and manually stuff this on the way
> out/unstuff on the way in. Far less dangerous than trying to
> manipulate packed data.
>
> Sometimes the transport mechanism forces you to use the same length
> for every component -- eg, X properties, where you can choose 1/2/4
> byte length and the server byteswaps for you.