By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,301 Members | 1,752 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,301 IT Pros & Developers. It's quick & easy.

ANSI and GNU regarding compatibility

P: n/a
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
Jul 15 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Have you included <math.hor <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.

On Jul 15, 12:47*am, Peng Yu <PengYu...@gmail.comwrote:
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
Jul 15 '08 #2

P: n/a
On Jul 15, 8:20 am, "Lucas V. Hartmann" <lucas.hartm...@gmail.com>
wrote:
Have you included <math.hor <cmath>, which is where M_PI
should be defined?
M_PI should not be defined in <math.hnor in <cmathfor 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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientÚe objet/
Beratung in objektorientierter Datenverarbeitung
9 place SÚmard, 78210 St.-Cyr-l'╔cole, France, +33 (0)1 30 23 00 34
Jul 15 '08 #3

P: n/a
On 2008-07-15 05:47, Peng Yu wrote:
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.

--
Erik Wikstr├Âm
Jul 15 '08 #4

P: n/a
On Jul 15, 5:03 am, Erik Wikstr÷m <Erik-wikst...@telia.comwrote:
On 2008-07-15 05:47, Peng Yu wrote:
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.
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
Jul 15 '08 #5

P: n/a
On 2008-07-15 19:05, Peng Yu wrote:
On Jul 15, 5:03 am, Erik Wikstr├Âm <Erik-wikst...@telia.comwrote:
>On 2008-07-15 05:47, Peng Yu wrote:
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.

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.

--
Erik Wikstr├Âm
Jul 16 '08 #6

P: n/a
On Jul 16, 11:15*am, Erik Wikstr÷m <Erik-wikst...@telia.comwrote:
On 2008-07-15 19:05, Peng Yu wrote:
On Jul 15, 5:03 am, Erik Wikstr÷m <Erik-wikst...@telia.comwrote:
On 2008-07-15 05:47, Peng Yu wrote:
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.
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.
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,

--
gpd
Jul 16 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.