On Wed, Aug 29, 2007 at 01:10:24AM -0400, Micah Anderson wrote:
>
> After discussing this with upstream, the following information was
> determined:
>
> util-vserver is using c99 as its compiler, which has support for
> unsigned long long, and isn't defining __STRICT_ANSI__ at all. In fact
> it seems like gcc -std=c99 defines __STRICT__ANSI__ and that gcc defines
> __STRICT_ANSI__ regardless of which ISO standard is specified.
>
> linux/types.h should define __u64 if __STDC_VERSION__ >= 199901L and it
> doesn't seem like it does. So this seems like it may be a problem in
> the linux headers.
>
There's some historical baggage here, I suspect. See the gcc man page
definition of -ansi:
-ansi
In C mode, support all ISO C90 programs. In C++ mode, remove GNU
extensions that conflict with ISO C++.
This turns off certain features of GCC that are incompatible with
ISO C90 (when compiling C code), or of standard C++ (when
compiling C++ code), such as the "asm" and "typeof" keywords, and
predefined macros such as "unix" and "vax" that identify
the type of system you are using. It also enables the undesirable
and rarely used ISO trigraph feature. For the C com‐
piler, it disables recognition of C++ style // comments as well as
the "inline" keyword.
The alternate keywords "__asm__", "__extension__", "__inline__" and
"__typeof__" continue to work despite -ansi. You would
not want to use them in an ISO C program, of course, but it is
useful to put them in header files that might be included in
compilations done with -ansi. Alternate predefined macros such as
"__unix__" and "__vax__" are also available, with or
without -ansi.
The -ansi option does not cause non-ISO programs to be rejected
gratuitously. For that, -pedantic is required in addition
to -ansi.
The macro "__STRICT_ANSI__" is predefined when the -ansi option is
used. Some header files may notice this macro and
refrain from declaring certain functions or defining certain macros
that the ISO standard doesn’t call for; this is to
avoid interfering with any programs that might use these names for
other things.
Functions which would normally be built in but do not have semantics
defined by ISO C (such as "alloca" and "ffs") are not
built-in functions with -ansi is used.
The problem is that when support C99 was added to gcc, and the -std=
option was added, it seems that specify -std with any option, include
C99, results in __STRICT_ANSI__ being defined. But many header files
(both system header files as well as potentially other
package-provider header files) still assume that __STRICT_ANSI__ means
strict ANSI C89 / ISO C90.
I recall that util-vserver is manually undef'ing __STRICT_ANSI__ to
work around similar issues with another header file. So that would my
suggested workaround pending filing a bug with the linux-libc-dev
package and waiting for the bug to resolved.
I'd also question the value of explicit specifying -std=c99 by default
when building packages normally, but that's between you and your
upstream.
Regards,
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
