Date: Wed, 12 Jun 1996 11:09:09 GMT From: James Raynard <fhackers@jraynard.demon.co.uk> To: bde@zeta.org.au Cc: freebsd-hackers@freebsd.org Subject: Re: Header files Message-ID: <199606121109.LAA05014@jraynard.demon.co.uk> In-Reply-To: <199606120041.KAA21730@godzilla.zeta.org.au> (message from Bruce Evans on Wed, 12 Jun 1996 10:41:59 %2B1000)
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> Bruce Evans <bde@zeta.org.au> writes:
>
> >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 see. Thanks.
> I actually plan to declare fpos_t as __BSD_OFF_T__ and define __BSD_OFF__
> using __attribute__.
I've got some patches (which I'll commit tonight) that get stdio to
compile cleanly with gcc -Wall. I tried throwing in a few more
warnings, including -ansi, just for fun, and got tons of complaints
about fpos_t, which is why I started looking at it. (Although -ansi
isn't really appropriate for this kind of code anyway).
> >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').
It should be be written as 0xffffffffUL, as you mention below.
> 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.
Oh, I didn't realise that.
--
James Raynard, Edinburgh, Scotland
james@jraynard.demon.co.uk
jraynard@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606121109.LAA05014>