ANSI and GNU regarding compatibility

**Lucas V. Hartmann** · Jul 15 '08, 06:25 AM

Re: ANSI and GNU regarding compatibility

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...@gmai l.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

**James Kanze** · Jul 15 '08, 09:45 AM

Re: ANSI and GNU regarding compatibility

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:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

**=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=** · Jul 15 '08, 10:05 AM

Re: ANSI and GNU regarding compatibility

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

**Peng Yu** · Jul 15 '08, 05:15 PM

Re: ANSI and GNU regarding compatibility

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

**=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=** · Jul 16 '08, 09:25 AM

Re: ANSI and GNU regarding compatibility

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

**gpderetta** · Jul 16 '08, 10:45 AM

Re: ANSI and GNU regarding compatibility

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

ANSI and GNU regarding compatibility

ANSI and GNU regarding compatibility

Comment

Comment

Comment

Comment

Comment

Comment