size of (foo) bug (no patch, it's too hard)

[Peter Seebach]

There's two bugs here, one probably easy to fix, one probably hard to fix.

The problem here is in tests for size of int/long/etc, done using a test
program looking like
        printf("%d", sizeof(foo));

This code is unequivocally wrong; we don't know for sure what type size_t is,
but we know for sure it's not int, because it is necessarily an unsigned type.
However, this becomes much worse on a big-endian system where size_t is larger
than int!  On such a system, it is not necessarily the case that this will
print the right values at all.

It is probably safe enough to simply cast the sizeof to int, because we can
reasonably assume that sizeof(x) will probably not be 32,768 or more on any
hardware, and int must have at least that much range.

There is a second, much more subtle, bug, which I encountered while trying to
cross-compile pdksh, using an x86 box, targeting ARM.

The obvious behavior if you just use CC=.../arm-linux-gcc is wrong; the
conftest program is arm-only, and the host is x86, so the binary won't run.

However, using a host compiler is *also* wrong, because there is no inherent
proof that the host and target systems will have the same sizeof.

I'm pretty sure that the correct thing to do is not to try to create a #define
for size of int, size of long, etcetera, or if you do, to do it in terms of
range, or just to use sizeof(type) in #if directives, because it's a
compile-time constant and expected to work in such contexts.  However, I'm
pretty sure you can't generally solve the problem of how to correctly identify
sizeof(type) in a cross-compile environment.

If it were up to me, I'd put the cast in in the test, but also provide an
explicit warning somewhere that the use of this test will break
cross-compiles, which (now that there are targetable handhelds with
too little memory for big compiles) may be a problem for some users.

-s