5 ms·

I am not a C programmer but my opinion with any language is don’t try to catch mistakes like this in the compiler. Instead leave to configurable and competing l

I am not a C programmer but my opinion with any language is don’t try to catch mistakes like this in the compiler. Instead leave to configurable and competing linters for people who want to catch possible mistakes like this. Anyone caught by this mistake probably hasn’t tested their program adequately. Any mistake induced by the wrong constant number should be easy to weed out with unit testing.

scatters 7y ago
By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler. It's a bit different for clang, which is modular and provides libraries that tool writers can use, but gcc is intentionally monolithic.
- gchadwick 7y ago
  > By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler. Does depend on what kind of lint you want to catch but something like this 'just' needs some lexing and parsing to give a usable AST that's reasonably clean so it's not too hard to write lint rules against it. (Not trivial for C & C++ hence 'just') Building the full compiler is much more work, especially if you want a decent optimizing compiler.
  - barrkel 7y ago
    The back end is a lot of work, but so is the front end in a language like C++. In fact most of the essential complexity is in the front end; you make do with a simple back end, but the front end is irreducibly complex if you want it to actually compile the language to spec. And you need the front end to lint, especially if you want to avoid false positives, the bane of linting tools.
    - zaarn 7y ago
      And better hope you didn't put in any bugs that GCC does or doesn't have, then you're left helpless as linter and compiler engage in epic battle on who is right.
  - antisemiotic 7y ago
    It's not just nontrivial for C++, you need a full template engine just to properly parse it [1]. Same thing for languages with a lisp-like macro system. Or languages that allow dynamic redefinition od symbols [2]. [1] http://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html http://blog.reverberate.org/2013/08/parsing-c-is-literally-u... [2] https://www.perlmonks.org/?node_id=663393 https://www.perlmonks.org/?node_id=663393
simion314 7y ago
Unit tests will not catch all issues, the person that writes the unit test will probably not see a corner case when implementing the code so it won't add the test for that corner case in the unit test either.
- dspillett 7y ago
  Or if the same person is writing the test as the code it is testing, given this is a syntax error rather than a logic error, it is likely that the test will be flawed similarly. A test passing just means that the code and the test agree, not necessarily that both are correct.
deleted 7y ago
[deleted]
DownGoat 7y ago
Not including a linter in the earlier C compilers are one of the hughe mistakes of that area. Compilers absolutely should have linters, they are very valuable tools. Think about all the common security mistakes in your average C application that could have been avoided over the years with a linter. I'm pretty sure Dennis Ritchie at some point himself said that not including a linter was a mistake, but I cannot find a quote of this with a quick search.
- Crinus 7y ago
  Back in the day most people actually ignored the few warnings compilers would give them, i do not think that having a linter would be used much (and AFAIK there were some).
  - gumby 7y ago
    "Back in the day?" Check out your system's log file for a scary collection of horror shows. Or compile most packages these days. In defense: configuring a package that is compiled by lots of people on lots of machines with lots of versions of various compilers requires a lot of attention to warning flags and such. If you aren't starting out a package from a blank buffer it's very hard to get this right. But I am frequently shocked by the number of compiler warnings I get from code downloaded from public repos and compiled in precisely the environments it's been documented to have been tested on.
- pjmlp 7y ago
  He at least said that it was a requirement for the buggy code he saw being written. "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." -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
archi42 7y ago
By that logic you could get rid of a lot of warnings. TBH, I think getting good warnings is a major feature of modern compilers.
NikkiA 7y ago
The kind of developers who are likely to make this mistake are probably not the kind of developers who will use advanced tools including linters or likely doing unit testing. Some may even have released code that still has these time bombs waiting to occur.
pjmlp 7y ago
lint was developed in 1979 (https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html) and we had to wait until clang for many developers start caring about actually using static analyzers. Every external tool is a lost opportunity for quality enforcement.
- inlined 7y ago
  Static analyzers existed long before the clang compiler. SAL from Microsoft is used extensively in every codebase I’ve worked with in Windows and it’s amazing, even if you have to get used to macros on all your functions’ parameters. https://docs.microsoft.com/en-us/visualstudio/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/code-quality/u...
  - pjmlp 7y ago
    Surely, and I appreciate its existence. Just making the point that they have been largely ignored.
    - geezerjay 7y ago
      That is not a fair assertion. You might have ignored static analyzers until you've discovered clang, but that observation is not generalizable. As others have already pointed out, lint has been used extensively for decades.
      - pjmlp 7y ago
        I have been using static analysers since the mid-90's. Ever heard of PC Lint from Gimpel? It was my first one. Or do you think I would be critic of how many use C, without adopting best practices myself? One learns a lot about code quality, or lack thereof, when doing enterprise consulting.
        naikrovek 7y ago
aidenn0 7y ago
GNU's C linter is GCC warnings. For C, making a linter isn't a big deal, but for C++ writing a robust C++ parser is so hard that the linter will need to use the compiler's parser anyways.

scatters 7y ago

By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler. It's a bit different for clang, which is modular and provides libraries that tool writers can use, but gcc is intentionally monolithic.

gchadwick 7y ago
> By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler. Does depend on what kind of lint you want to catch but something like this 'just' needs some lexing and parsing to give a usable AST that's reasonably clean so it's not too hard to write lint rules against it. (Not trivial for C & C++ hence 'just') Building the full compiler is much more work, especially if you want a decent optimizing compiler.
- barrkel 7y ago
  The back end is a lot of work, but so is the front end in a language like C++. In fact most of the essential complexity is in the front end; you make do with a simple back end, but the front end is irreducibly complex if you want it to actually compile the language to spec. And you need the front end to lint, especially if you want to avoid false positives, the bane of linting tools.
  - zaarn 7y ago
    And better hope you didn't put in any bugs that GCC does or doesn't have, then you're left helpless as linter and compiler engage in epic battle on who is right.
- antisemiotic 7y ago
  It's not just nontrivial for C++, you need a full template engine just to properly parse it [1]. Same thing for languages with a lisp-like macro system. Or languages that allow dynamic redefinition od symbols [2]. [1] http://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html http://blog.reverberate.org/2013/08/parsing-c-is-literally-u... [2] https://www.perlmonks.org/?node_id=663393 https://www.perlmonks.org/?node_id=663393

simion314 7y ago

Unit tests will not catch all issues, the person that writes the unit test will probably not see a corner case when implementing the code so it won't add the test for that corner case in the unit test either.

dspillett 7y ago
Or if the same person is writing the test as the code it is testing, given this is a syntax error rather than a logic error, it is likely that the test will be flawed similarly. A test passing just means that the code and the test agree, not necessarily that both are correct.

deleted 7y ago

[deleted]

DownGoat 7y ago

Not including a linter in the earlier C compilers are one of the hughe mistakes of that area. Compilers absolutely should have linters, they are very valuable tools. Think about all the common security mistakes in your average C application that could have been avoided over the years with a linter. I'm pretty sure Dennis Ritchie at some point himself said that not including a linter was a mistake, but I cannot find a quote of this with a quick search.

Crinus 7y ago
Back in the day most people actually ignored the few warnings compilers would give them, i do not think that having a linter would be used much (and AFAIK there were some).
- gumby 7y ago
  "Back in the day?" Check out your system's log file for a scary collection of horror shows. Or compile most packages these days. In defense: configuring a package that is compiled by lots of people on lots of machines with lots of versions of various compilers requires a lot of attention to warning flags and such. If you aren't starting out a package from a blank buffer it's very hard to get this right. But I am frequently shocked by the number of compiler warnings I get from code downloaded from public repos and compiled in precisely the environments it's been documented to have been tested on.
pjmlp 7y ago
He at least said that it was a requirement for the buggy code he saw being written. "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." -- https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html

archi42 7y ago

By that logic you could get rid of a lot of warnings. TBH, I think getting good warnings is a major feature of modern compilers.

NikkiA 7y ago

The kind of developers who are likely to make this mistake are probably not the kind of developers who will use advanced tools including linters or likely doing unit testing. Some may even have released code that still has these time bombs waiting to occur.

pjmlp 7y ago

lint was developed in 1979 (https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html) and we had to wait until clang for many developers start caring about actually using static analyzers. Every external tool is a lost opportunity for quality enforcement.

inlined 7y ago
Static analyzers existed long before the clang compiler. SAL from Microsoft is used extensively in every codebase I’ve worked with in Windows and it’s amazing, even if you have to get used to macros on all your functions’ parameters. https://docs.microsoft.com/en-us/visualstudio/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/code-quality/u...
- pjmlp 7y ago
  Surely, and I appreciate its existence. Just making the point that they have been largely ignored.
  - geezerjay 7y ago
    That is not a fair assertion. You might have ignored static analyzers until you've discovered clang, but that observation is not generalizable. As others have already pointed out, lint has been used extensively for decades.
    - pjmlp 7y ago
      I have been using static analysers since the mid-90's. Ever heard of PC Lint from Gimpel? It was my first one. Or do you think I would be critic of how many use C, without adopting best practices myself? One learns a lot about code quality, or lack thereof, when doing enterprise consulting.
      - naikrovek 7y ago

aidenn0 7y ago

GNU's C linter is GCC warnings. For C, making a linter isn't a big deal, but for C++ writing a robust C++ parser is so hard that the linter will need to use the compiler's parser anyways.