I wish HN had a downvote option for submissions

I know there exists one because one of my posts has -4 lol

The downvote button is below the upvote button

Credible or not, the article was evidently written by someone on the ISO C committee, which makes it noteworthy and topical for HN.

> please see its comments why not credible

Most of the comments are of low-quality; I can hardly find a single nugget of anything that stacks against the opinions given in the article.

I'm on the fence. I'm actually surprised that, for instance, strerror doesn't return "const char * ".

However, the proposed change is a low-value fix.

Except for the dynamically generated cases for unknown error numbers, the strings are static text that can be represented by write-protected string literals.

GNU Linux:

  $ cat strerror.c
  #include 
  #include 
  
  int main(void)
  {
    char *x = strerror(ERANGE);
    *x = 0;
    return 0;
  }

  $ gcc strerror.c -o strerror
  $ ./strerror 
  Segmentation fault (core dumped)

This arguably not as good as a compile-time check. Though in some ways it is better because it cannot be casually dismissed with a cast! No matter what tortuous paths the returned pointer takes through the bowels of the program, and how it is converted, at the end, if it is dereferenced to perform a write, the machine will catch it.

In any case, the main point is that we don't have a heisenbug here. If the offending code executes at all, there is a predictable and instant access violation.

The insidious problems in C programs that people struggle with are the ones where something is inadvertently modified without detection and causes a misbehavior at some later time, in an unrelated part of the program. The const qualifier helps with this, if people use it judiciously in their code bases. Adding a sprinkling of const to a code base that was developed without const can find some of these kinds of bugs.

There is no chance of that happening here; the hardware protects the strerror strings, and will kill the program at the first misuse. Which means, people have already debugged those situations, and all we will get from the const is a bunch of annoying false positives.

No, not every hardware has a MMU for the above to be possible; ISO C is not just for platforms with memory management. But anyway, we have those platforms. Maybe people should port as much of their code as possible to more robust platforms with better tooling and test the heck out of it.

A code base that has been Valgrind-ed and Asan-ed to smithereens on Linux, but is running on some MMU-less embedded chip, is probably in better shape than similar code that hasn't been so treated.

ISO C is a portability standard; it can help people write code which is portable, which then allows it to be exposed to the tools and approaches available from diverse platforms. Not every kind of bug has to be caught on every available platform. It's okay to use one platform that has good diagnostics and tools to harden some code, which then gets ported to some obscure chip using a compiler that has poor diagnostics, and where the run-time has very little error checking in the hardware or libraries.

Okay, now here is an alternative opinion. strerror obviously should return a const-qualified pointer. What, I'm surprised that it doesn't; how did that even happen?

Anyway, we can do that without introducing any false positives for existing code. The reason is that people compiling legacy code should be using the compiler options to select the legacy dialect. So, that is to say, compiling code in C90 or C99 mode would produce the old strerror declaration without const.

If old code is breaking for you due to a new standard, it's because you're inappropriately failing to restrict the dialect to the one in which the code was written!

C99's introduction of // comments broke contrived C90 code like this:

   z = x//*divide by y*/y
   ;

But, in 2020, I can still compile that with "gcc -std=c90" or "gcc -ansi", and it nicely divides x by y.

The "can't make the slightest change that will diagnose or break old code!" knee-jerk reaction betrays an ignorance about compiler support for multiple historic standards.

chronological order would be a good option. I sometimes never get to the other pages when there are hundreds of comments.