Bruno Haible <[EMAIL PROTECTED]> writes: > Globally, I think this is backwards: 'copysign' is a more general function > than 'signbit',
That's true in general but this is a special case. 'copysign' has been standardized since 1985, is well understood, and is available on many older platforms. 'signbit' was standardized far more recently, and is not available on many platforms that are still shipping, e.g., Solaris 9. >> Normally the 'signbit' implementation relies on undefined behavior, as >> it accesses the "wrong" member of a union > > This is the point of a 'union'. The code is not casting pointers; it is > using 'union's for the purpose they were defined for. Nevertheless, the behavior is undefined (see section 6.2.6 of C99), and optimizing compilers are free to substitute other behavior. The code might work in the Autoconf test, but fail in other uses. This sort of thing has caused real problems in the Linux kernel, and it's why the Linux folks compile with special GCC options. >> This is safer for traditional platforms like Solaris 9 that >> have copysign but not signbit. > > What do you mean by "safer"? I am worried about compilers that optimize away references to memory, as the C standard entitles them to. > 1) It relies on functions only available in libm.... In Solaris, copysign is in -lm. If we can't assume -lm then we probably shouldn't bother trying to use copysign. Come to think of it, perhaps a better approach is to replace 'unsigned int' with 'unsigned char' in the implementation of signbit, of course redoing all the macros accordingly. That would remove the objection of undefined behavior. This is because there is a special exemption in the C standard for accessing storage of character type; e.g., see C99 section 6.2.6.1 paragraph 5.
