[GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Nicklas Larsson]

> On 1 Feb 2021, at 08:56, Moritz Lennert <mlennert at club.worldonline.be> wrote:
> 
> Thanks for the clarification.
> 
> In light of that I agree that we should choose the oldest standard possible, unless we _really_ need something only present in a more recent version.
> 
> @those who want to use more recent standards: what are your reasons for that ?
> 
> Moritz



The immediate reason for me bringing this issue up to the ml, was the question on whether to include the standard header <inttypes.h> (introduced with C99) for using printf format specifier. Something that would simplify portability.

It is my general impression that the newer standards, apart from adding new features to the language, make it somewhat stricter (thus probably safer) and actually improves portability.

The portability issue from our point of view, I presume, is rather the degree of the compilers’ (and platforms’) support of the standards. On this field, there has been major progress since last time this was discussed (correct me if I’m mistaken) some 10 years ago and especially in the last couple of years.
In particular, MSVC is notoriously lagging in support for new C standards, with Visual Studio 2013 giving only partial support of C99 [1]. Wheras gcc added "substantially complete support” for C99 with GCC 4.5 [2] and for C11 as of 4.9 [3].
Last year support for (required features of) C11 and C17 was added with Visual Studio 2019 version 16.8 [4]. Clang, being a relatively new contestant, supports most of latest standards [5].

As noted by Markus and Māris, present code base doesn’t conform to C89/C90. I might add the use of inline to the list of non-C89. Inlines is a feature added with C99 (although GNU has it as an extension to C89 [6]).
In light of this fact alone, I think it would be good to reconsider recommendations/directions on C standard requirements. I can hardly imagine someone take the time to back-port relevant code just for the sake of it. If C89 doesn’t cut it, then what will? It feels natural to then jump to the next standard, C99.

The crux of the matter is that changes from C99 to C11 aren't cumulative, but in practice (at least partly) made C11 more lax. Some features introduced as mandatory in C99 were made optional in C11. This is, I suppose, the reason for the still only partly supported C99 in msvc, whereas proper support of C11 and C17 was added.

On the other end of the line of standards, there is the C17, which doesn’t bring any news compared to C11, but is rather a bug fix for the former [7]. Code written for C11 will work in C17 mode and the other way around, but the actual compiled code depends on the compiler. In order not to potentially exclude max. C11 compatible compilers (e.g. 4.9 > GCC < 8.1), I’d say C11 support is preferable to C17.

In short, there is a lot to take into consideration. For me, C11 (perhaps with mandatory feature support only) still seem to be the best candidate. What platforms, compilers being used for future development of GRASS do not meet that requirement?
I’d like to emphasise, setting new requirements for C code is first and foremost important for new or otherwise updated code. No need to “modernise” the whole code base.

Regarding C++. I don’t know to what extent existing code comply to any standard. I do know that at least PROJ, GEOS, GDAL adhere to C++11, which is a de facto standard in most open source projects. If we would set a requirement and I believe we should, C++11 should be the one at this date.


GRASS did not only survive but also evolved beautifully, through decades of tech changes, by making strategic moves forward at the right time. I agree with Māris that, in the end, this is a question for PSC.


Cheers,
Nicklas



[1] https://devblogs.microsoft.com/cppblog/c99-library-support-in-visual-studio-2013/
[2] https://gcc.gnu.org/c99status.html
[3] https://gcc.gnu.org/wiki/C11Status
[4] https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
[5] https://clang.llvm.org/compatibility.html
[6] https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Inline.html
[7] https://gcc.gnu.org/legacy-ml/gcc-patches/2017-10/msg02121.html