[Proj] NAD problems on OSX 10.5 Leopard

[Karl Swartz]

> >Ah, the extra bytes are pointer for the *cvs part of the CTABLE  
> >structure?
> >
> > fwrite(ct.cvs, tsize, 1, stdout)

No.

> >Or is it written as part of the &ct fwrite?
> >
> > fwrite(&ct, sizeof(ct), 1, stdout)

Yes.  The cvs element of that structure is a pointer, which is 32-bits
in x86 mode and 64-bits in x86-64 mode.  The extra four bytes are due to
the larger pointer.

> This works:
> 
> if (fwrite(&ct.id, sizeof(ct.id), 1, stdout) != 1 ||
> 	fwrite(&ct.ll, sizeof(ct.ll), 1, stdout) != 1 ||
> 	fwrite(&ct.del, sizeof(ct.del), 1, stdout) != 1 ||
> 	fwrite(&ct.lim, sizeof(ct.lim), 1, stdout) != 1 ||
> 	fwrite(ct.cvs, tsize, 1, stdout) != 1) {
> 	fprintf(stderr, "output failure\n");
> 	exit(2);
> }

That doesn't write the pointer, so yes, it should work, so long as both
architectures have the same format for ther other values (which is true
for x86 and x86-64).

> So, is sizeof(struct CTABLE) supposed to be the size including the  
> *cvs pointer?

Of course.

> sizeof(&cd.id) + sizeof(&cd.ll) + sizeof(&cd.del) + sizeof(&cd.lim)

In this case it should work though in general it will not since it
assumes no padding.  For example, if MAX_TAB_ID were 1 or 81 (it's
actually 80), an x86 compiler should add three pad bytes so cd.ll is
aligned on a 4-byte boundary.  On some architectures (and on x86 if
you use gcc's -malign-double option), there will be seven pad bytes
in this example, or other amounts depending upon the alignment of a
double.

(Again, on x86 and x86-64, there should be no padding so this should
work.)

A better way of writing this would be

    #include <stddef.h>

    if (fwrite(&ct, offsetof(ct, cvs), 1, stdout) != 1)
        ...

The avoids writing out the pointer (which is useless anyway) but depends
on cvs being the last element of the structure.

Writing each element individually (as you did above) is the safest,
depending only on the encoding of the underlying types.

 -- Karl