Date: Tue, 14 May 2002 15:10:13 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Stefan Farfeleder <e0026813@stud3.tuwien.ac.at> Cc: Bill Fenner <fenner@research.att.com>, <obrien@FreeBSD.ORG>, <standards@FreeBSD.ORG> Subject: Re: signbit ISO C99 macro Message-ID: <20020514145305.N2616-100000@gamplex.bde.org> In-Reply-To: <20020513183118.GB228@stefan.fafoe>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 May 2002, Stefan Farfeleder wrote: > On Mon, May 13, 2002 at 11:13:58AM -0700, Bill Fenner wrote: > > > > It's easy if it's easy to treat doubles as uint64_t's. Like, I think > > signbit() might be something like > > > > #define signbit(d) (*((uint64_t *)&(d)) & UINT64_C(0x8000000000000000)) > > > > or maybe > > > > #define signbit(d) (*((uint64_t *)&(d)) >> 63) > > > > However, that assumes that d is an IEEE double (and there is a > > possibly-incorrect assumption about byte order). I don't know how to The current libm seems to make similar assumptions. It uses 2 32-bit "words" instead of uint64_t, so it has to fight endianess problems involving the inter-word order, but it doesn't do anything special for the bits in the words. Does IEEE specify the bit order and/or sign bit enough for this to actually be correct? > > implement a macro that will take any real-floating type. The macro could expand to a function call. That's how I would implement it until/unless it is actually used enough for its efficiency to matter. > signbit isn't limited to lvalues, is it? You'll have to handle eg > signbit(3.0) too. Right. This could be handled using a gcc macro that assigns the arg to an lvalue if necessary. Where did this thread start? ISTR a PR that implements all the new floating point classification functions. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020514145305.N2616-100000>