5 ms·
So you expect to compiler to give you style points for your code? To be clear: it isn't just coincidentally identical behaviour, it is defined by the standard
by st_goliath 6y ago
So you expect to compiler to give you style points for your code?
To be clear: it isn't just coincidentally identical behaviour, it is defined by the standard to be equivalent.
- rbanffy 6y agoIt should at least emit a humorous message asking the developer what are they really trying to accomplish by that.
- MaxBarraclough 6y agoYes, compilers should warn on indisputably poor style, even when program behaviour might still be correct. This is helpful to the programmer, who probably didn't intend to write their code that way. Fortunately compilers already do this. GCC will warn you about unused variables, for instance.
- pjmlp 6y agohttps://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html > To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. To this day, the best result regarding adoption of such tooling places it around 11%. I wonder how much education we need to keep fighting for adoption.
- yakubin 6y agoMost compilers will warn about misleading indentation. This is misleading indexing. A program containing misleading indentation is also standards-compliant, but that's completely irrelevant when talking about what code should trigger warnings.
- eequah9L 6y agoThen again, it's not common that people make the mistake of confusing an array with an index. Misleading indentation is a somewhat common issue. So it makes sense to have the latter as a warning, but probably nobody thought of adding a warning for the former, or just decided to not bother coding it up.
- st_goliath 6y agoMisleading indentations, unused variables, unused goto labels and the like are a quite good indicator that there is something wrong here. The thing we are talking about here is issuing warnings for "but that's not how we usually do it". When you add a new warning to a C compiler, you will break build processes all over the planet that have "-Werror" turned on and/or have management that insists on warnings being addressed. Some of those build processes compile decade old, safety critical production code. Code that has a couple hairy, stylistically sucky places in it. Code that sometimes does weird but perfectly valid things because those portions were ported over from assembly back in the 80ies. (And yes, I can guarantee you first hand that the situation I describe here is very real) C compilers have become critical infrastructure and meddling with their internals and their behavior poses real word risks. Adding a whole new compiler warning must be carefully considered and better have a damn good reason. "This pattern in the syntax tree strongly indicates that there is something wrong in the code" is a good reason. "This is not how I usually write code" needlessly forces people to rewrite finicky code that has been working perfectly for decades in safety critical environments, for no reason other than you not liking e.g. the order of operator arguments.
- pjmlp 6y agohttps://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html > To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.