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

[Denis Ovsienko]

On Thu, 28 Jan 2021 09:27:29 +0000 (UTC)
Nicklas Larsson via grass-dev <grass-dev at lists.osgeo.org> wrote:

> - C11

Hello list.

I have read the full thread, it seems best to reply to the initial
message in one go to cover several inter-related concerns discussed in
different messages. Hopefully you will find some useful bits in this
rather lengthy message. Much of the solution space described below is
the result of long-term work by Guy Harris (CCed) and is based on his
knowledge of C standards and their actual implementation in compilers,
please excuse me if my interpretations are sometimes inaccurate.

Currently my main exposure to C is in tcpdump, which has been developed
for 30 years, and to which I have been contributing for about 8 years.
tcpdump originated in the world where old UNIXes and non-x86
architectures were common. Some of the involved C compilers never made
it beyond C89 in terms of standards, so for tcpdump for many years C89
had to remain the house standard.

tcpdump build system had evolved to provide automatic compensation for
the differences between different architectures, operating systems,
compilers and libc implementations. In practical terms, if you compiled
with GCC on GNU/Linux, the compiler flags would include "-std=c89", and
you would get at least a warning (if not an error) for a C99 feature.
This way you would know it would break on Ultrix (or elsewhere) with
an old compiler before it happened. The point here is, C standard
compliance can be enforced to a significant degree without a reviewer
having to proof-read every change manually.

Another useful feature of that build system is that if a file named
".devel" exists in the source tree directory (it does not by default),
it enables plenty of compiler warnings automatically. The actual
compiler flags are different in each case depending on which C compiler
it is, and which version of it is, but the point is, to enable all
available warnings, the end user does not even have to know which C
compiler they are using. When you need to establish that the source
tree compiles without warnings on their system, it is enough to ask to
run "touch .devel && ./configure && make -s clean && make -s" and to
report the output.

Not long ago it became obvious that some of the old UNIXes could not be
supported in tcpdump anymore, in that no developer and no known user
had access to a running copy of these. So the approach changed from "try
to work on any UNIX-like OS" to "this is the list of what works and can
be tested". Before tcpdump I had closely observed the same problem in
another C free software project, which tried to be compatible with way
too many UNIX-like OSes for its developer budget. It did not work well.

As far as I can see, the natural DIY approach usually works better, in
that when someone uses OS XYZ and wants the software to work there, and
contributes quality changes to achieve that without breaking other
systems, that's great and it would be wrong to get in their way. Just
saying "this software should work on XYZ, everybody get that done for
me" does not work well. So when you are considering supporting an
OS/distribution, it helps to see how many representatives it has in
the project.

The retiring of unpracticable targets in tcpdump made it possible to
observe that every OS on the supported list had at least a C99
compiler. So the requirement in the build system was bumped from C89 to
C99, which had made the work a little bit easier due to integer types,
trailing commas, designated inits and other features that make practical
difference here and there in tcpdump code base. But it is still a lot
of other work to do, and even going forward one more C standard would
not change that. As far as my contributions go, C99 is good enough not
to get in the way of the actual programming.

To answer one other comment made on the difference between C standards,
I usually refer to this web-site (of course there are many others) to
look up the nuances that I do not remember:
https://en.cppreference.com/w/c

Regarding "long-term support" distributions, these are not always as
well supported as they seem to be. The vendors would be happy to be
paid for "supporting" a distribution that was released 10 years ago.
But what is sometimes delivered is just an old system with old software
and old bugs. In such a case, when there is an old system that ships
with GRASS 6 or GRASS 5, you don't have any obligation to keep that
combination in a good working order, even if the user is paying some
money to some 3rd party.

Likewise, you don't have any obligation to make the current GRASS work
on such an old system. tcpdump can be and often is at both the bleeding
edge and the trailing edge at the same time, as its must-have
dependencies are only libc and libpcap. Its current version works on
Linux so long as the kernel is a reasonably new 2.6.x. GRASS is written
in three programming languages and there are so many dependencies that
more than 3-4 years of backward compatibility would be an unreasonable
level of commitment.

So I'd say it helps to take "long-term support" with a grain of salt.
Of course, if the vendor is willing to help you achieve the extra
backward compatibility (see DIY above), that's a good trade-off for
everyone, but usually it is not the case.

Thus, as far as I can figure it out, if GRASS developers at some point
establish that C17 gives GRASS particular significant technical
advantages, it should be fine to declare C17 the house standard if (and
only if) your currently active platforms reliably support C17. But if
you resolve to stick with C89 or C99 for a few more years, that would
be fine as well.

-- 
    Denis Ovsienko