Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Jan 2019 00:43:07 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc:        Pedro Giffuni <pfg@freebsd.org>, freebsd-numerics@freebsd.org
Subject:   Re: Undefined Behavior in lib/msun/src/e_pow.c (was Re: New math library from ARM)
Message-ID:  <20190114235426.I1062@besplex.bde.org>
In-Reply-To: <20190101183226.GA11443@troutmask.apl.washington.edu>
References:  <797a7755-db93-1b9c-f3b9-8850d948e098@FreeBSD.org> <20181231151904.GB823@troutmask.apl.washington.edu> <20181231152230.GC823@troutmask.apl.washington.edu> <06c8b6a2-ed26-f255-3947-c79b593a9dea@FreeBSD.org> <20190101045425.GA5767@troutmask.apl.washington.edu> <d01c8770-5431-0634-4ecc-37069ff76458@FreeBSD.org> <20190101055225.GA5982@troutmask.apl.washington.edu> <e6bd09b3-35c6-922b-1b4d-de27e424a627@FreeBSD.org> <9cdce84b-2cff-d752-67a9-4c9ef391cc2c@FreeBSD.org> <20190101183226.GA11443@troutmask.apl.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Jan 2019, Steve Kargl wrote:

> On Tue, Jan 01, 2019 at 10:01:45AM -0500, Pedro Giffuni wrote:
>>
>>>> This would be easy
>>>> to see if all declarations are grouped together. In additional,
>>>> don't you need to include stdint.h to get uint32_t?
>>>
>>> Well, my patch did compile, but I will match the existing style if
>>> the change is accepted/desired.
>
> Yeah, I found that out myself.  I cannot find where stdint.h is
> being pulled into the build.  It seems that one of the included
> headers may have some namespace pollution.

Both u_int32_t and uint32_t are standard [Free]BSD pollution in
<sys/types.h>.  The library can reasonably depend on this.

stdint.h should rarely be included when compiling msun.  It is currently
included directly in about 6 source files but never as pollution.  Some
of the standard pollution in <sys/types.h> is implemented by including
<sys/_stdint.h>.  This is now excessive and results in declaring all
standard integer types (which <sys/types.h> is permitted to declare)
and some macros (WCHAR_MAX, WCHAR_MIN, and sometimes RSIZE_MAX which
depends on SIZE_MAX which is not defined via pollution) which <sys/types.h>
is not permitted to declare.  The extras for the standard integer types
are not even under __BSD_VISIBLE.

The 6 includes of <sys/stdint.h> seem to be just style bugs for using
uint64_t.  Even FreeBSD-4 declares both u_int64_t and uint64_t.

Also, most includes of <stdint.h> including all the ones in msun are
excessive.  Standard integer types are declared in <inttypes.h>.
<stdint.h> includes <inttypes.h> and adds mistakes like PRI* support
and non-mistakes like prototypes for strto[u]imax().

msun now uses (signed) int32_t a lot, and this depends on more than the old
u_foo_t pollution in <sys/types.h>, so msun has required FreeBSD features
for a long time and is less portable than fdlibm.  Including <inttypes.h>
and changing all the u_foo_t's to ufoo_t's would be a lot of churn and
would break portability to C90.  <inttypes.h> should be included in at
most math.private.h and math_private.h should provide consistent spellings
more like ufoo_t than u_foo_t

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190114235426.I1062>