Re: 'signbit' patch to use 'copysign' if available

[Paul Eggert]

Bruno Haible <address@hidden> 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.