Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jun 2010 00:30:53 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        David Schultz <das@FreeBSD.org>
Cc:        Kostik Belousov <kostikbel@gmail.com>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r209110 - in head/lib/msun: . src
Message-ID:  <20100616001659.G38908@delplex.bde.org>
In-Reply-To: <20100615131443.GA93094@zim.MIT.EDU>
References:  <201006121732.o5CHW5Cs065722@svn.freebsd.org> <20100615084939.GL13238@deviant.kiev.zoral.com.ua> <20100615131443.GA93094@zim.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Jun 2010, David Schultz wrote:

> 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.
>
> Better would be to remove the symbols from libc and have them in
> libm where they belong, but I'm not sure if that would break anything.

Better move Standard C symbols from libm to libc where they belong
:-).  Even Unix programmers should not be too surprised now if the
Standard part of the libm namespace becomes more reserved.  (It is
already partly reserved -- gcc warns about use of cos() without
including <math.h>, and once you have included <math.h> the whole
compile-time libm namespace is reserved.)

BTW, c89 is missing the -lm needed to make it a C compiler, and its
man page doesn't say anything about this.  Similarly for gcc (?, man
page too large to check).

Bruce



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