On Wed, Dec 1, 2010 at 9:16 PM, Garrett Cooper <gcoo...@freebsd.org> wrote:
> On Wed, Dec 1, 2010 at 8:57 PM, David Schultz <d...@freebsd.org> wrote:
>> On Tue, Jun 15, 2010, David Schultz wrote:
>>> On Tue, Jun 15, 2010, Kostik Belousov wrote:
>>> > On Sat, Jun 12, 2010 at 05:32:05PM +0000, David Schultz wrote:
>>> > > Author: das
>>> > > Date: Sat Jun 12 17:32:05 2010
>>> > > New Revision: 209110
>>> > > URL: http://svn.freebsd.org/changeset/base/209110
>>> > >
>>> > > Log:
>>> > > Introduce __isnanf() as an alias for isnanf(), and make the isnan()
>>> > > macro expand to __isnanf() instead of isnanf() for float arguments.
>>> > > This change is needed because isnanf() isn't declared in strict POSIX
>>> > > or C99 mode.
>>> > >
>>> > > Compatibility note: Apps using isnan(float) that are compiled after
>>> > > this change won't link against an older libm.
>>> > >
>>> > > Reported by: Florian Forster <o...@verplant.org>
>>> >
>>> > May be, it makes sense to remove the default version for the isnan symbol
>>> > ?
>>>
>>> Wouldn't this mean apps that use isnanf() directly will no longer
>>> compile? isnanf() is a historical BSD interface, and although
>>> it's been deprecated for many years, it's still declared (if
>>> __BSD_VISIBLE).
>>>
>>> Oops, to complicate matters further, I just noticed that we
>>> already have isnanf and __isnanf symbols in libc, so maybe the new
>>> symbol isn't needed. (isnan() and isnanf() are in libc because
>>> that's where they were historically.) The second version in
>>> libm looks like a mistake (wrong scope of the #if 0 in s_isnan.c.)
>>> Perhaps we could just remove the duplicate symbols from libm.
>>
>> Any thoughts on removing the isnanf and __isnanf symbols from
>> libm? Both symbols are already in libc for historical reasons, so
>> the duplication isn't needed.
>>
>> Although we've had the duplicate isnanf symbol in libm for several
>> releases, I don't believe removing it will cause problems; apps
>> will just pick up the libc version. __isnanf is only present in
>> libm in 9-CURRENT (due to the commit referenced above). Because
>> of symbol version differences, however, removing it will affect
>> apps that were linked under 9-CURRENT AND rely on isnanf AND link
>> against libm before libc. On my system, libwebkit is the only
>> affected binary I could find.
>
> Yeah... it's going to be broken according to the manpage (manpage
> explicitly calls out -lm and math.h) and POSIX (POSIX only calls out
> math.h) as math.h lives in lib/msun for C apps:
>
> $ find /usr/src/ -name math.h
> /usr/src/contrib/libstdc++/include/tr1/math.h
> /usr/src/contrib/libstdc++/include/c_compatibility/math.h
> /usr/src/lib/msun/src/math.h
>
> So unless math.h is going to move to libc, I'd leave it alone if I
> was making the final call.
Arg -- please ignore this email. I did another search and you said
isnanf, not isnan. It's not mentioned anywhere in POSIX land or in any
of our manpages.
Sorry bout that,
-Garrett
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
