Tru64 and 2.2 problems - cast-to-union

[Scott Adkins]

--On Wednesday, July 23, 2003 11:23 AM +0100 Christos Soulios 
<soulbros at noc.uoa.gr> wrote:

> I also compiled cyrus-imapd-2.2.1-BETA on a Solaris 9 box with Forte C
> compiler. I had some of the same problems, which come from the fact that
> cyrus is mostly gcc compiler oriented.
>
>> [text deleted about (union cyrus_config_value) type cast stuff]
>
> This is because there is a cast to a union. Union casts are not ansi C
> compliant, but a gcc extension.
>
> What I did is to remove the cast to a union type. This makes the syntax
> ansi c compliant.

Right, this is what I did as well... basically, I was left with the int
and const char * type casts, which naturally generated warnings.

> However, I had some warnings for the assignments of integers to a char *.
> In my case (Sun with Solaris 9) this creates no further problems, because
> the char *s and the integer members of the union share the same memory.
> But I am not sure what happens with different architectures that although
> the union members share the same memory, the byte alignment between the
> string and the integer may differ.

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
issue may definitely be a problem, and I don't know if that will affect
us.  The only thing I can really do is maybe write a little test program
that does what the Cyrus code was trying to do and see how it is stored.

I looked at the command line options of CC to see if I could loosen up the
ANSI compliant restrictions a bit and make it work... there is an option
called -noansi_alias that does that, but it didn't help.  I then found some
documentation where it is explicitely stated that Tru64 CC does not support
the union-to-cast extension and has no intension of doing so in the future.
So, there you have it.

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?

I would be in favor of simply modifying the imapopts structure so that we
can make it work without portability problems... something I may look at
down the road... whether CMU is interested that is another question.

Scott
-- 
 +-----------------------------------------------------------------------+
      Scott W. Adkins                http://www.cns.ohiou.edu/~sadkins/
   UNIX Systems Engineer                  mailto:adkinss at ohio.edu
        ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
 +-----------------------------------------------------------------------+
     PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 231 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20030724/eb97e53b/attachment.bin