Undefined Behavior in lib/msun/src/e_pow.c (was Re: New math library from ARM)

Bruce Evans brde at optusnet.com.au
Mon Jan 14 13:43:15 UTC 2019


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


More information about the freebsd-numerics mailing list