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

[Ben Scott]

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.

> 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.

  In theory, one can use implementation-specific features to turn a
struct into something a little more predictable.  Like those pragma's
mentioned earlier in the thread.  But you're hosed if you move to a
different compiler that doesn't support the same features.

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

> 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).

  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.

  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.

  Things used to get real interesting back in the day on MS-DOS
systems, where you had dozens of different compilers and languages,
mostly without source, and usually without documentation on internals.

-- Ben