
I wish HN had a downvote option for submissions - hivolix
I think a dislike button option could be helpful to stop spreading biased and false information like this recent highly upvoted HN submission (please see its comments why not credible) :
https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=24108109<p>Link title is: &quot;C will never stop you from making mistakes&quot;
======
pwg
Once you accumulate a "small karma threshold" (quote from the HN FAQ) you can
'flag' submissions. Flagging is the closest to a "dislike" option available.
But it is suggested to use it for items that are off topic.

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](https://news.ycombinator.com/newsfaq.html)

[edit]: add additional clarity

------
keiferski
Disagree strongly. Downvotes add a level of toxicity that should be avoided as
much as possible. Ignoring an undesirable link is better than having a
negative reaction to it. The lack of a downvote button also forces any critics
to leave a comment explaining their criticism, rather than just mindlessly
pressing the down arrow.

------
tmaly
To be honest, I think the down vote is abused sometimes. It would be nice to
see who down voted a comment. Transparency could help correct the abuse.

~~~
zzo38computer
I think what would be helpful is to have an option to ignore all voting for
purpose of sorting, so that you can vote if you want to, but if you don't like
to, you can disable that option and it will display only in the chronological
order (it could hide the voting options too if you wanted to, but I suppose it
doesn't have to do).

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

------
verdverm
There is a downvoting feature for comments when you have enough HN karma
points. 500 iirc

~~~
hivolix
Thanks. I updated the title to be more precise

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

------
kazinator
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 <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)
    

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.

------
lemoncurd
bias is not bad

