[GRASS-dev] C and C++ standards used by GRASS

GRASS GIS GRASS GIS developer
1

Hello,

which C and C++ standards we are using? And which we want to use? Do we even care? Since we can always fix it if somebody wants to build GRASS on some other compiler than relatively new GCC.

For example, lib/gis build fails with gcc option -std=c89 [1] because of missing hypot buildin [2].

I’m not sure if I already asked about it but I found only K&R function discussion.

Thanks,
Vaclav

[1] http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins

[2] http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options

PS: For Python, we have particular version specified (but for Python, it is more critical).

2

Vaclav Petras wrote:

which C and C++ standards we are using? And which we want to use? Do we
even care? Since we can always fix it if somebody wants to build GRASS on
some other compiler than relatively new GCC.

C code is supposed to conform to C89 and POSIX.

There are no standards for C++ code.

For example, lib/gis build fails with gcc option -std=c89 [1] because of
missing `hypot` buildin [2].

hypot() is specified by POSIX.

Using -std=c89 or -ansi will, by default, omit the POSIX extensions
from any headers which are specified by C89. To re-enable them, you
need something along the lines of:

  -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE -D_SVID_SOURCE

We already require POSIX for open() etc, so there isn't much point in
excluding POSIX functions which are declared in the C89 headers.

--
Glynn Clements <glynn@gclements.plus.com>

3

On Fri, Mar 28, 2014 at 5:40 PM, Glynn Clements <glynn@gclements.plus.com>wrote:

Vaclav Petras wrote:

> which C and C++ standards we are using? And which we want to use? Do we
> even care? Since we can always fix it if somebody wants to build GRASS on
> some other compiler than relatively new GCC.

C code is supposed to conform to C89 and POSIX.

There are no standards for C++ code.

I would say that for GCC, we should go with:

‘c++98’‘c++03’
The 1998 ISO C++ standard plus the 2003 technical corrigendum and some
additional defect reports. Same as -ansi for C++ code.
(http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options)

I'll will set this for may compilation and see what will happen. The only
alternative is to say that all C++ capable compilers will be new anyway and
than we can go with latest (C++11 or later).

> For example, lib/gis build fails with gcc option -std=c89 [1] because of
> missing `hypot` buildin [2].

hypot() is specified by POSIX.

Using -std=c89 or -ansi will, by default, omit the POSIX extensions
from any headers which are specified by C89. To re-enable them, you
need something along the lines of:

        -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE -D_SVID_SOURCE

We already require POSIX for open() etc, so there isn't much point in
excluding POSIX functions which are declared in the C89 headers.

Hm, I hoped that I missed some -posix in GCC but there is apparently none.

And if you are unsure about that -D options, I don't know how to enforce
the right standards.

So, we have all GNU GCC extensions enabled which is good in the sense that
we have many functions available. The bad thing is that it is hard to say
which are allowed without looking to the standard.

--
Glynn Clements <glynn@gclements.plus.com>

4

Vaclav Petras wrote:

> There are no standards for C++ code.
>

I would say that for GCC, we should go with:

‘c++98’‘c++03’
The 1998 ISO C++ standard plus the 2003 technical corrigendum and some
additional defect reports. Same as -ansi for C++ code.
(http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options)

I'd suggest C++98 for C++ code, although whether you can get people to
follow it is another matter. The original version of r.terraflow
hard-coded the use of g++ in the Makefile.

Hm, I hoped that I missed some -posix in GCC but there is apparently none.
And if you are unsure about that -D options, I don't know how to enforce
the right standards.

The precise details are platform-specific. In general, the use of
extensions is tolerated more in non-critical modules and less in core
libraries and critical modules.

--
Glynn Clements <glynn@gclements.plus.com>