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