4 ms·

> int test(void) { > int i[3] = {0}; > > return i[8]; > } clang will warn. gcc will warn with -Wall -O2. > int *test(void) { >

by clarry 9y ago

> int test(void) { > int i[3] = {0}; > > return i[8]; > } clang will warn. gcc will warn with -Wall -O2. > int *test(void) { > int i; > > return &i; > } You are free to use -Werror. I encourage people to learn to use their tools first. Instead of whining about the language when it is their tools that do not do what you want by default.

simias 9y ago
Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Still only a warning though. And I don't think -Werror is a good general purpose solution because it's too broad. Many warnings are just fine as warnings and for big projects that build on several operating systems using a lot of 3rd party libraries there's bound to be a few harmless warnings here and there. For instance the perfectly valid "if (a && b || c)" will warn with -Wall. I guess I'd want a "-Werror-on-serious-warning". That's why sane defaults matter, if those warnings were errors to begin with they would be fixed upstream, if instead you decide unilaterally to turn on -Werror for your code then you're screwed if your third party headers weren't as stringent with their coding rules.
- clarry 9y ago
  > Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Right. So GCC isn't really a static analyzer. But it does the analysis that is required to perform certain optimizations, and as a side effect you also get some new warnings with the optimizations enabled. > And I don't think -Werror is a good general purpose solution because it's too broad. It sure is too broad for all existing software to compile, but if we're talking about security-critical software, what is with this double standard of bashing C for the lack of stringent checks per the standard and at the same time requiring compatibility with third party software that isn't built to the same standard? I think if you're doing something security critical, then you must want the same stringent checks from all the libraries you use. Which means you choose the good libraries, or make your own, or fix the existing ones. Yes, positive encouragement from sane defaults could push other projects into doing the right thing, but as long as they don't, you really don't have to use their bad code in your security critical product. Yet, it is entirely usable. OpenBSD for instance compiles the kernel and libcrypto among other things with -Werror. Other parts of the system may be built with less stringent checks. It is, by the way, possible to only turn specific errors into warnings with -Werror=... Likewise, you can disable specific annoying warnings. I agree that it would be nice if compilers provided sane set of warnings (and errors) out of the box without any extra tweaking. I think we're getting closer and closer thanks to clang pushing things in that direction. On the other hand, I don't suppose people will ever agree which warnings are the right ones. I'd say most people who want stringent checks will enable -Wall and -Werror, and they will add the parentheses in the expression you mentioned, even if it is completely legit without them.
  - kbenson 9y ago
    > It sure is too broad for all existing software to compile, but if we're talking about security-critical software The problem I have with this is the assumption that software you write that may be used by others can easily be classified into security-critical software and non-security-critical software. Sometimes you don't know, sometimes it changes ten years later as something gets pulled in and used because it's easier, multiple times over the years until the original author of a portion of the code may be entirely unknown, much less their intention for whether it was sufficiently robust for security critical situations (think an OSS library that may have forked a few times, and copied small bits of code such as utility functions from some other projects). It's time to switch to safety by default. We should fail safe, and require flags to allow previously failing code to compile, not to just hear that it might cause a problem.
    - clarry 9y ago
      Right, that is why I proposed people to use -Werror, even if that means you have to vet and fix third party code (which you should do anyway if you're depending on it). Ideally you use other tools too. Apart from that, don't assume flags and static analyzers can save you. If you're building something security critical, you do not make any assumptions about the code you depend on. You don't assume it is in some class. You don't "don't know", you vet the code. Flags and analyzers, default or not, are at best going to save you from a small subset of problems. The code might still be completely backwards and insecure.

by clarry 9y ago

simias 9y ago

Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Still only a warning though. And I don't think -Werror is a good general purpose solution because it's too broad. Many warnings are just fine as warnings and for big projects that build on several operating systems using a lot of 3rd party libraries there's bound to be a few harmless warnings here and there. For instance the perfectly valid "if (a && b || c)" will warn with -Wall. I guess I'd want a "-Werror-on-serious-warning". That's why sane defaults matter, if those warnings were errors to begin with they would be fixed upstream, if instead you decide unilaterally to turn on -Werror for your code then you're screwed if your third party headers weren't as stringent with their coding rules.

clarry 9y ago
> Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Right. So GCC isn't really a static analyzer. But it does the analysis that is required to perform certain optimizations, and as a side effect you also get some new warnings with the optimizations enabled. > And I don't think -Werror is a good general purpose solution because it's too broad. It sure is too broad for all existing software to compile, but if we're talking about security-critical software, what is with this double standard of bashing C for the lack of stringent checks per the standard and at the same time requiring compatibility with third party software that isn't built to the same standard? I think if you're doing something security critical, then you must want the same stringent checks from all the libraries you use. Which means you choose the good libraries, or make your own, or fix the existing ones. Yes, positive encouragement from sane defaults could push other projects into doing the right thing, but as long as they don't, you really don't have to use their bad code in your security critical product. Yet, it is entirely usable. OpenBSD for instance compiles the kernel and libcrypto among other things with -Werror. Other parts of the system may be built with less stringent checks. It is, by the way, possible to only turn specific errors into warnings with -Werror=... Likewise, you can disable specific annoying warnings. I agree that it would be nice if compilers provided sane set of warnings (and errors) out of the box without any extra tweaking. I think we're getting closer and closer thanks to clang pushing things in that direction. On the other hand, I don't suppose people will ever agree which warnings are the right ones. I'd say most people who want stringent checks will enable -Wall and -Werror, and they will add the parentheses in the expression you mentioned, even if it is completely legit without them.
- kbenson 9y ago
  > It sure is too broad for all existing software to compile, but if we're talking about security-critical software The problem I have with this is the assumption that software you write that may be used by others can easily be classified into security-critical software and non-security-critical software. Sometimes you don't know, sometimes it changes ten years later as something gets pulled in and used because it's easier, multiple times over the years until the original author of a portion of the code may be entirely unknown, much less their intention for whether it was sufficiently robust for security critical situations (think an OSS library that may have forked a few times, and copied small bits of code such as utility functions from some other projects). It's time to switch to safety by default. We should fail safe, and require flags to allow previously failing code to compile, not to just hear that it might cause a problem.
  - clarry 9y ago
    Right, that is why I proposed people to use -Werror, even if that means you have to vet and fix third party code (which you should do anyway if you're depending on it). Ideally you use other tools too. Apart from that, don't assume flags and static analyzers can save you. If you're building something security critical, you do not make any assumptions about the code you depend on. You don't assume it is in some class. You don't "don't know", you vet the code. Flags and analyzers, default or not, are at best going to save you from a small subset of problems. The code might still be completely backwards and insecure.