Date: Wed, 12 Jun 1996 10:41:59 +1000 From: Bruce Evans <bde@zeta.org.au> To: fhackers@jraynard.demon.co.uk, freebsd-hackers@freebsd.org Subject: Re: Header files Message-ID: <199606120041.KAA21730@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>2. The stdio library requires fpos_t to be an 8-byte type. In stdio.h,
> it's typedef'd as an off_t if neither _ANSI_SOURCE or
> __STRICT_ANSI__ are defined, with a comment saying "When we switch
> to gcc 2.4 we will use __attribute__ here."
> Do we have any plans to switch to gcc 2.4? 8-)
I plan to fix this when we switch to gcc-2.7. The necessary attribute is
__attribute__((__mode__(__DI__))
but __DI__ isn't supported in versions of gcc before 2.7. gcc-2.4 through
gcc-2.6 support
__attribute__((__mode__(DI))
but this can't be used since an application might define DI.
I actually plan to declare fpos_t as __BSD_OFF_T__ and define __BSD_OFF__
using __attribute__.
>3. <machine/limits.h> has a comment saying that 2147483648 is an
> unsigned int for 32-bit two's complement ANSI compilers. However,
> it's an unsigned long for 32-bit ANSI compilers, regardless of the
> binary encoding used.
Ugh. The corresponding problem doesn't occur for UINT_MAX because
UINT_MAX is defined as a hex literal and the type rules work more
naturally for hex. However, our ULONG_MAX is broken in the opposite way
(it has type `unsigned').
The comment could be fixed by writing 0x80000000. I prefer to write all
the limits in hex anyway. I did this for 386BSD-0.1 and FreeBSD-1.x
inherited the changes, but 4.4BSDLite did it differently. NetBSD writes
all the limits in hex and uses `U' and `L' suffixes to get the types
right. It also uses a `U' suffix for UCHAR_MAX and USHRT_MAX to get the
types wrong (`unsigned', but should be `int' for the i386, since the
integral promotions convert both unsigned char and unsigned short to int.
There are longstanding bugs and bogons in our definitions of the quad
limits. A comment says that gcc requires that they be written as
expressions. This isn't true for gcc-2.6. gcc in fact screws up the
expressions. E.g., this breaks strtouq(). strtouq("4294967296", 0, 0)
returns 18446744073709551615ull instead of 4294967296ull
(18446744073709551615 may be more recognisable if it is written as
0xffffffffffffffff or 2^64 - 1). This is fixed in gcc-2.7.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606120041.KAA21730>