Link title is: "C will never stop you from making mistakes"
The better way to make sure items you find to be "positive" make the front page is to upvote everything you think deserves to get there. Upvote the positive, ignore the negative, and the negative will fade from view.
https://news.ycombinator.com/newsfaq.html
[edit]: add additional clarity
> 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 <string.h>
#include <errno.h>
int main(void)
{
char *x = strerror(ERANGE);
*x = 0;
return 0;
}
$ gcc strerror.c -o strerror
$ ./strerror
Segmentation fault (core dumped)
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
;
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.