On Thu, 28 Jan 2021 09:27:29 +0000 (UTC) Nicklas Larsson via grass-dev <grass-dev@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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev