Tru64 and 2.2 problems - cast-to-union

[Robert Urban]

Scott Adkins wrote:
> Yes, this is a concern for me... I am not exactly sure how this will be
> stored in Tru64.  We are talking about a "char *" and an "int" stored in
> the same location.  I have always known them to consume 4 bytes of memory,
> but my manager isn't so sure, thinking that maybe it is 8 bytes of memory
> these days for more efficient storage.  The little-endian and big-endian

alpha is 64-bit.  It conforms to the LP64 standard (long/pointers are 64
bits).  Thus under normal circumstances pointers and longs ("long int")
are 64 bits == 8 bytes.  A union of "char *" and "int" will be 8 bytes long.

For completeness I mention the compiler and linker flags "-taso", "-xtaso",
and "-xtaso_short", which can be used to force the compiler/linker to make
virtual addresses fit within 32-bits, and also make pointers 32-bits
long, but unless you're trying to compile horribly unportable code you
should avoid these.

> Isn't there a more portable way of doing this?  Requiring GCC for the
> compilation of Cyrus is a bit too strict, in my opinion.  Rob sent another
> message out asking me why I just don't use GCC anyways, because it would
> be simpler than them rewriting the code to make it more portable.  I just
> don't agree with that... in fact, the Tru64 CC compile is highly optimized
> for the platform, takes advantage of all the pipelining and special ways
> that the architecture is designed to execute code.  Sure, Compaq supplied
> a bunch of code to GCC, but it is nowhere near what is already in the CC
> compiler, and on top of that, the engineers there have stated that they
> are constantly comparing CC to GCC to see how it compares, and CC always
> blows away GCC with regards to performance.  Why switch to GCC and lose
> any performance gains we would have had just to support a GCC specific
> extension which is a bit controversial in nature to begin with?

also, if the DECC compiler can compile something, because of its
strictness the chances are very good that other compilers will too.
That is, getting rid of errors that DECC brings to light makes the code
cleaner...

Rob Urban