This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: struct stat
Geoff Keating wrote:
>
> OK. How about this patch? The alpha, sparc, and mips, and solaris2
> ports need to follow.
>
> I haven't tested it yet, since it doesn't actually change anything on
> my system (I only have gcc).
>
> Compilers that don't support __extension__ should #define it to empty
> (or, better yet, just ignore it as a token, then they do support it).
> Compilers that don't support 'long long' should #define
> __NO_LONG_LONG.
Hmm...I don't see any __extension__ in my <gnu/types.h>. When did
this get there? My feeling on this (and I'm probably in the
minority, again), is that glibc should #define __extension__ as
empty if we're not using __GNUC__. That, or there should be
a separate clause in which uquad_t is defined without the use
of __extension__. The whole problem with __GNUC__ is that it
brings in all sorts of non-standard stuff. I'd like to avoid doing
that when __GNUC__ isn't defined.
> --
> Geoffrey Keating <geoffk@ozemail.com.au>
>
> ===File ~/patches/glibc-48.diff=============================
> 1999-03-16 Geoff Keating <geoffk@ozemail.com.au>
>
> * sysdeps/unix/sysv/linux/bits/types.h: Add a new type,
> __arith64_t, which is a 64-bit arithmetic type (that is, it's 8
> bytes long). Change the guard on 'long long' uses to be
> !__NO_LONG_LONG rather than __GNUC__.
I think the maintainers would like to keep __GNUC__ as an enabler for
the long long code.
-Dave