News for hackers. Stuff that matters.
Re:Two musings on the design of compiler warnings by PaulHoule on Wednesday September 02, 2020 @02:18PM (#24356091)
There is a set of concerns in this article that are universal, and then there are the specifics of C, which generally leave me horrified that because some rando is free to write

  if((this=that)) {
    ...
  }
some hackers can crash the power grid, blow up a chemical plant, etc. Using the double paren to suppress warnings is frankly terrifying to me because the double paren is the kind of thing that comes out of the ten thousand monkeys that almost understand Noam Chomsky that are trying to 'help' me in my IDE or when I type with a touchscreen -- the same accidents that might result in "this=that" could just as well leave double parens...

OTOH in more civilized languages the question of error messages is fascinating to me but insufficiently documented, in fact it is part of the "parser generators haven't improved since yacc" syndrome. "Little languages" like the ones yacc was invented to make easy haven't taken off in the way that yacc's siblings did because of a handful of problems that haven't been addressed in one tool -- and the error handling is the worst of them.

I told the Jena people that I thought error handling with their RETE engine was great -- I could look at the error and look at the Jena source code and understand what was wrong with my source code. That was just not the case with Drools.

Re:Two musings on the design of compiler warnings by saagarjha on Wednesday September 02, 2020 @05:22PM (#24358307)
See, I think your problem is specifically with the fact that C provides the same operator for "assignment" and "assignment and I get a value back". The issue is that the latter is useful but generally not what you want, so this is why we warn about it but I don't think it's justified to be horrified about it.