On portable C programming (was: libraw1394 struct layouts...)

[Thomas Charron]

On Thu, Jan 8, 2009 at 12:06 AM, Ben Scott <dragonhawk at gmail.com> wrote:
> On Wed, Jan 7, 2009 at 11:31 PM,  <VirginSnow at vfemail.net> wrote:
>> So what's the recommended way to do this?
>  I dunno that there really is any really good way.

int32_t and int64_t are your friends.  :-D

>> One way might be to expose a function/method for
>> accessing each structure member.
>  That's probably the only truly portable way, but it's cumbersome as hell.

  That's the 'proper' way to do it, for many reasons besides things
already mentioned.  By using successors to get and set variables you
can offer protection and insulation of internal variables from the
'cruel, cruel world'.

>  Maybe there's a better way and I just don't know it.  I'm far from a C expert.

  In order to safely pass a data structure around, you really need to
be able to serialize it in some way, and then reistantiate the struct
after the fact.  If you don't, you get EXACTLY what you have here.
It's a nearly identical problem to little endian vs big endian
processors.   Dumping structs is a bad, bad, UBAH bad idea.

>> But a lot of existing code isn't written that way.
>  Correct.  Welcome to the real world.  It's defective (and I want my
> money back).

  Ok Meatloaf.  :-D

>  Linux and *BSD often get away with these non-portable practices
> because so much stuff comes with source and can be easily re-built.
> As long as everything is built with the same compiler and the same
> compiler options and for the same architecture, the same internal
> representations will be used, so nobody notices.  But then you have
> neat things like file formats which "change" depending on the hardware
> the program was compiled for.

  Do many modules have this issue?  I'm ignorant to what a whole lot
of modules are currently using.  Modules I've written use int32_t and
int64_t.

>  This is also a big part of the reason why binary compatibility is
> hard.  A binary package (.rpm, .deb, etc.) built in one environment
> (kernel + compiler + libraries + compiler options + build options +
> target architecture + ...) won't necessarily be compatible with a
> different environment.  RPM refuses to install subtly different
> packages for good reason.

  I shudder when I remember libc hell.  "Welcome to DLL Hell!  Now,
FOR LINUX!"..  :-D

-- 
-- Thomas