Re: signbit #define'd causes compilation error in octave

[Eric Blake]

On 10/18/2011 02:51 PM, Michael Goffioul wrote:
> Hi,
>
> With a current version of gnulib and MSVC10, I get a compilation error
> in octave due to signbit being #define'd by gnulib's math.h module.
> The configure script ends up with GNULIB_SIGNBIT being 1 and
> REPLACE_SIGNBIT being 1. This causes signbit being #define'd as
>
> #  define signbit(x) \
>     (sizeof (x) == sizeof (long double) ? gl_signbitl (x) : \
>      sizeof (x) == sizeof (double) ? gl_signbitd (x) : \
>      gl_signbitf (x))
>
> The problem is that one octave file defines a class with a method
> called signbit. This leads to a syntax error in the compiler. Now,
> when looking signbit documentation, it looks like it should be a
> macro. So is octave wrong when using signbit as a class method name?

If octave were written in C, then I would say you are correct, and that 
octave is in error; inclusion of <math.h> renders a program 
non-compliant for using 'signbit' in any context where the macro 
expansion would be undesirable.  But this is because signbit _must_ be a 
macro in C (since C has no method overloading).

But since octave is written in C++, we could avoid the macros and 
instead have three overloaded functions named signbit which operate on 
the correct types, so as not to pollute the namespace with a macro. 
POSIX does not speak to C++ compliance, so using overloads instead of a 
macro for C++ does not cause any non-compliance issues.  We've done 
method overloads in the past for functions like strstr which must be 
type-unsafe in C, but which can usefully have two overloads for proper 
type safety in C++.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org