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>