Tru64 and 2.2 problems

[Christos Soulios]

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.

>  2) So, I get past the above, and run right smack into another problem,
>     this time with lib/imapopts.c.  I get over a 100 lines of errors along
>     the lines of the following:
> 
>     {IMAPOPT_ADMINS,"admins",0,(union config_value)((const char 
> *)""),OPT_STRING},
>     ---------------------------^
>     {IMAPOPT_ALLOWALLSUBSCRIBE,"allowallsubscribe",0,(union 
> config_value)((int)0),OPT_SWITCH},
>     -------------------------------------------------^
>     {IMAPOPT_ALLOWNEWNEWS,"allownewnews",0,(union 
> config_value)((int)0),OPT_SWITCH},
>     ---------------------------------------^
> 
>     Basically, ever line in that table generates an error on the union
>     construct.  I don't understand the error message, been even more so, I
>     don't understand why the union is even there at all.  It appears that
>     this file is automatically generated by the following command:
> 
>       ../tools/config2header imapopts.c imapopts.h < imapoptions
> 
>     The config2header script talks about playing an interesting game to get
>     the union to initialize itself in a syntacticly valid manner, namely to
>     initialize the union itself and not the members of the union, as well
> as
>     to ensure that the union is initialized to something of a type that is
>     in that union.  What do I say about that?  Very bizarre, and it doesn't
>     work in Tru64.
> 
>     Doing a mass delete of all the '(union config_value)' stuff in the file
>     gets the code to compile, but I don't know what kind of problems that 
> is
>     going to cause me if it has to do with initializing things.
> 
>     Any thoughts on how to handle this problem?
> 
>     I get similar errors when compiling libcyr_cfg.c as well, but in a
>     slightly different context, and doing the same deletion gets it to at
>     least compile.
> 
This is because there is a cast to a union. Union casts are not ansi C
compliant, but a gcc extension. 

Please see : 
http://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html
and
http://groups.google.com/groups?q=union+cast+group:comp.lang.c.*&hl=en&lr=&ie=UTF-8&group=comp.lang.c.*&selm=21259%40mimsy.umd.edu&rnum=3

What I did is to remove the cast to a union type. This makes the syntax ansi c
compliant. 
By default the compiler sets the rvalue to the first member of the union. 
And because the union is 
union config_value {
       const char *s;
       int i;
       int b;
};
the compiler assigns the value to the char *s member of the union. For this
reason every assignment to a string gets perfectly compiled.

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.


>  3) After that, it compiles for awhile and then stops on imap/protocol.c
>     with the following error:
> 
>       cc: Error: ./../lib/prot.h, line 209: Missing ";". (nosemi)
>       __attribute__ ((format (printf, 2, 3)));
> 
>     Looking in lib/prot.h, I see the following:
> 
>       extern int prot_printf(struct protstream *, const char *, ...)
>           __attribute__ ((format (printf, 2, 3)));
> 
>     What is that supposed to do?  I simply deleted the line that has the
>     __attribute__ on it and put a semicolon on the previous line and it
>     compiles.  What problems will I see by doing that?
> 

__atribute__ keyword handling is done at the configure script and for compilers
that do not support this extension there is a #define statement. However,  a
'#include <config.h>' statement is missing from the lib/prot.h file and for this
reason it does not build with other than gcc compilers. If you add it, then it
is ok.

Regards,
  Christos


-- 
/**
 * Christos Soulios
 * Department of Informatics
 * University of Athens
 * e-mail : soulbros at noc.uoa.gr
 */