Re: adasockets and adatypes

[Ole-Hjalmar Kristensen <ohk@clustra.com>]

Simon Wright <simon@pushface.org> writes:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> 
> > Note that while I may complain about this from time to time, you're
> > still better off than you are with C in the same situation. In C you
> > have very little control over representation and in general just
> > have to rely on the fact that most C compilers choose to do things
> > basically the same way. The one advantage C has in this area is that
> > it is at least simpler to take just about any data structure and
> > treat it as raw bytes. You can get there in Ada, but it does require
> > more work.
> 
> 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.

And don't forget that there are automated tools for doing this in C,
the most widespread is probably SUN's XDR/rpcgen, which always has
been freely available.  From an XDR interface specification, rpcgen
will happily generate both server and client side subs, and indeed a
skeleton server, if you wish. As the XDR format is a wire format,
there are no problems with different compilers and endianness.  rpcgen
essentially eliminated the extra manual work in writing bread and
butter client/server applications years ago.

Of course, there is nothing stopping you from calling the generated C
stubs from Ada.

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen