Re: open office

[Momchil Velikov <velco@fadata.bg>]

>>>>> "Adam" == Adam C Powell IV <hazelsct@mit.edu> writes:

Adam> Momchil Velikov wrote:
>> oly@tkk.att.ne.jp wrote:
>> > ../../unxlngppc.pro/obj/cpp.o: In function `error':
>> > ../../unxlngppc.pro/obj/cpp.o(.text+0xcdc): undefined reference to `__va_arg_type_violation'
>> 
>> The problem is that according to ANSI C,
>> the first argument to va_arg should be the type after
>> the default promotion. Simply stated, one can't
>> use va_arg (short, ap) but must use va_arg (int, ap).
>> With optimization turned on, GCC is able to (kind of)
>> detect such cases and that's the error you've got.
>> In short, StarOffice source is non-compliant.

Adam> I sent a patch to the KerberosKTH4 maintainer for this very
Adam> reason (in my post to debian-powerpc of 3/1/00 23:38:56 UTC),
Adam> but the maintainer rejected it on the grounds that "The code
Adam> looks fine to me, your patch would break it for shorts and on
Adam> alphas for longs as well."  In other words, it doesn't seem
Adam> right.  I can't say that I blame his logic...

Adam> Do you know where I can find the "long version" of what you've
Adam> "simply stated" above, so I can convince him to get the patch
Adam> into Kerberos- and maybe release it for a couple of new
Adam> platforms in 2.2r2?

Here is the relevant part of ISO C Working Draft, 1997-11-21, WG14/N794 J11/97-158:

     7.12.1.2 The va_arg macro

     Synopsis

1               #include <stdarg.h>
                type va_arg(va_list ap, type);

     Description

2 The va_arg macro expands to an expression that has the type and value of the next
     argument in the call.  The parameter ap shall be the same as the va_list ap
     initialized by va_start.  Each invocation of va_arg modifies ap so that the values
     of successive arguments are returned in turn.  The parameter type is a type name
     specified such that the type of a pointer to an object that has the specified type can be
     obtained simply by postfixing a * to type.  If there is no actual next argument, or if
     type is not compatible with the type of the actual next argument (as promoted
     according to the default argument promotions), the behavior is undefined.

Regards,
-velco