ANSI and GNU regarding compatibility

[Peng Yu]

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

I'm wonder what the general case is.

Thanks,
Peng

 

[Lucas V. Hartmann]

Have you included <math.h> or <cmath>, which is where M_PI should be
defined? Sometimes the most common header files are built-into the
compiler to speed up compilation, so gcc might accept M_PI even
without the header file included. I am pretty certain that M_PI is
standard, as even older C compilers (e.g. Borland Turbo C) supported
it.

 

[James Kanze]

Have you included <math.h> or <cmath>, which is where M_PI
should be defined?

M_PI should not be defined in <math.h> nor in <cmath> for a
standard compliant compiler. The C and C++ standards forbid it.
(But the Posix standard requires it. If, and only if,
_POSIX_C_SOURCE is defined.)

 

[Erik Wikström]

Hi,

ANSI and GNU C are different in some delicate aspects (I'm not sure
about C++). For example, M_PI is not in ANSI C but in GNU C.

Of course, to make my program most portable, I should go for ANSI. But
since ANSI lacks some convenient facilities, such as M_PI just
mentioned, I would like to use GNU C.

Now, the question is if a platform has ANSI C, what is the chance it
does not have GNU C? What is the chance that a GNU C can not be
installed at all? If in most platforms that have both ANSI C and GNU
C. Then I should just use GNU C.

If ANSI C is not enough go to the next best thing: POSIX (which, among
other things is where M_PI comes from). All UNIX/Linux systems that I
know of are more or less POSIX compatible and many C and C++ compilers
includes support for POSIX features as well. Building in compiler
dependencies in your code is a bad idea unless you really have to.

 

[Peng Yu]

If ANSI C is not enough go to the next best thing: POSIX (which, among
other things is where M_PI comes from). All UNIX/Linux systems that I
know of are more or less POSIX compatible and many C and C++ compilers
includes support for POSIX features as well. Building in compiler
dependencies in your code is a bad idea unless you really have to.

I would like my g++ compiler following POSIX. There is an options -
ansi to make it ANSI compatible. Is there an options to make g++ POSIX
compatible? Or g++ is already POSIX compatible without an option?

Thanks,
Peng

 

[Erik Wikström]

I would like my g++ compiler following POSIX. There is an options -
ansi to make it ANSI compatible. Is there an options to make g++ POSIX
compatible? Or g++ is already POSIX compatible without an option?

To my knowledge POSIX does not make any changes or additions to the C
language it only adds a number of library functions, so the compiler
have nothing to do with it.

 

[gpderetta]

To my knowledge POSIX does not make any changes or additions to the C
language it only adds a number of library functions, so the compiler
have nothing to do with it.

Every posix C compiler is also an ANSI C compiler, but not viceversa.

Posix does add extra requirements to the C language. For example
threading requires support from the compiler; CHAR_BIT must be 8 and a
posix system must also support a compiling environment were int is at
least 32 bits. IIRC it also requires that all pointers have the same
size (including function pointers).

HTH,