For code that must deal with hardware and thus is size specific, I tend to 
include a function early in the program that checks the assumptions.

#define         NUM_BYTES_IN_LONG               4

if( sizeof(long) != NUM_BYTES_IN_LONG )
{
    printf( "Dooh!  longs aren't 4 bytes long\n" );
    exit( EXIT_FAILURE );
}

I tend to write programs to access the internals on PCI cards to do quick 
diagnostics.  Having a simple sanity check helps keep the code 
portable.  Since it only runs once it's not a big performance issue.


At 10:12 PM 4/7/2006 -0400, Michael wrote:
>Hello,
>
> > I have been recently surprised to see that the following C program
> > has a different output on Solaris 10 and NetBSD 3, for the same
> > hardware (and both while using gcc):
> >
> > #include <stdio.h>
> > #define type(a) printf("sizeof(%s) = %d\n", "" # a, sizeof(a));
> > int main(void)
> > {
> >         type(char);
> >         type(short);
> >         type(int);
> >         type(float);
> >         type(double);
> >         type(long);
> >         type(long long);
> >         return 0;
> > }
> >
> > So on Solaris 10 I obtain:
> > $ ./sizes
> > sizeof(char) = 1
> > sizeof(short) = 2
> > sizeof(int) = 4
> > sizeof(float) = 4
> > sizeof(double) = 8
> > sizeof(long) = 4
> > sizeof(long long) = 8
> >
> > while NetBSD 3 gives:
> >
> > $ ./sizes
> > sizeof(char) = 1
> > sizeof(short) = 2
> > sizeof(int) = 4
> > sizeof(float) = 4
> > sizeof(double) = 8
> > sizeof(long) = 8
> > sizeof(long long) = 8
> >
> > ok, the only difference is actually the size of long integers,
> > respectively 32 and 64 bits. From my reading of the ANSI C standard I
> > understood this is possible.
>
>Check the resulting binary - on NetBSD it will be ELF64, on Solaris it's
>apparently 32bit.
>
> > I have a few questions about this though, if appropriate:
> > - who sets this?
>
>The compiler.
>
> > - why not keep long as 32 bits and let int default to 64 bits instead?
> >   This would help the short/long/long long hierarchy coherence, and
> >   let int default to the native processor size (and 486 would be 16
> >   bits!)
>
>Only if you run the 486 in real or 16bit protected mode.
>
> > - has this ever been observed to cause portability or stability issues
> >   on this platform?
>
>People blindly assuming sizeof(long) == 4 or - even worse sizeof(int)
>== sizeof(void *) - cause endless headaches.
>
> > My concern is, I have seen programmers assume sizeof(int) or
> > sizeof(long) are 32 bits, even while writing portable 32/64 bits code
> > (and I was myself wrong at first, since it is apparently very platform
> > dependant even on 64 bits hardware).
>
>Yes, and they're dead wrong. Code that assumes sizeof(long) ==
>sizeof(int) is /not/ portable, it will break when compiled on a 64bit
>target. This is also not really platform or OS dependent - in a 64bit
>binary running on solaris you'll get sizeof(long) == sizeof(void*) == 8
>
> > Morale => #include <stdint.h> ?
>
>If you depend on size use size-safe types like uint32_t and friends.
>
>have fun
>Michael