> On 1 Feb 2021, at 08:56, Moritz Lennert 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 (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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
