tags:

views:

342

answers:

3

Is there a good reason why this program compiles under GCC even with the -ansi and -pedantic flags?

#include <cmath>

int main (int argc, char *argv [])
{
     double x = 0.5;

     return static_cast<int>(round(x));
}

This compiles clean (no warnings, even) with g++ -ansi -pedantic -Wall test.cpp -o test.

I see two problems:

  1. round() shouldn't be available to C++ in ISO-conformant mode (since it comes from C99)
  2. Even if round() were available in this case, it should only be so from the std namespace

Am I wrong?

A: 

I might be off base here but doesn't gcc's -ansi flag apply to the code constructs (ie, disable GCC language extensions) rather than switching all libraries into strict ANSI compliant mode as well?

Timo Geusch
the man page to gcc states that some function will not be defined when the ansi flag is set, but not that only ansi functions will be defined
josefx
@josefx: See my comments to D. Shawley. After investigating more, I've learned that library extensions cannot "alter the behavior of well-formed programs". So it seems to me that adding a `round()` extension to the library would be illegal, which makes the behavior of the `-ansi` flag moot.
Dan Moulding
A: 

I believe that the Standards specify what symbols are required to be defined and in which header they are defined. I do not believe that the Standards state that no other symbols may be defined. More to the point, std::round() will not be defined by a free symbol called round() can be defined.

D.Shawley
Okay, that may be true but the purpose of `-ansi`, according to the GCC manual, is to *disable* all non-standard extensions. Any such additional library functions would be extensions of the standard (whether such extensions are allowed by the standard is tangential to this question).
Dan Moulding
I should amend my previous comment: `-ansi` disables *conflicting* extensions, while `-pedantic` is supposed to disable all extensions.
Dan Moulding
Actually, I've looked at both C and C++ standards and although they allow additional library functions, such extensions cannot "alter the behavior of any well-formed program". This implies that they cannot reserve any additional identifiers (i.e. a well-formed program that defines its own round() function would break by the library extending the standard with its own round function). Any additional library functions must have names that are *already* reserved, such as `_Round()`.
Dan Moulding
+1  A: 

This is a bug. It's been around for a surprisingly long while. Apparently, there has not been enough of a collective desire to fix it. With a new version of C++ just around the corner which will adopt the C99 functions from math.h, it seems unlikely it will ever be fixed.

Dan Moulding