8 ms·

Worth noting that some warning flags (at least when combined with -Werror* ) make the compiler not standard compliant. * It's been some time since I last parto

Worth noting that some warning flags (at least when combined with -Werror* ) make the compiler not standard compliant. * It's been some time since I last partook in language lawyering, and can't remember if standard compliant C compilers are allowed to produce diagnostics, the term used, for well-defined code as long as they also succeed.

mrguyorama 9y ago
Do you have an example I could take a look at? I'm actually not well versed in the C world
- YSFEJ4SWJUVU6 9y ago
  Unintended code (like having both arms of an if-else-statement execute the same action, or a duplicate condition in a logical expression) is sometimes perfectly valid as far as the standard goes. A double condition for example may simply be a result of poor refactoring, and thus the program even works as intended – however, the compiler cannot know that. That's why the helpful warnings flag those statements – -Werror then makes the compiler abort the compilation altogether on any warnings which is clearly not standard-compliant in cases like the one I outlined. The majority of the warning options showed in the article are intended to find unintended code (which can however perfectly defined if not intended behaviour as opposed to invalid, undefined behaviour). The very basic examples showed for those options also themselves do not contain anything that by itself would make the code not standard-compliant.
  - dkersten 9y ago
    Well, the standard does not say that if you ask the compiler to flag potentially suspect code that it should compile successfully. That doesn’t make it non standard if you decide you do want your compiler to stop compiling when it encounters potentially suspect code and enable that mode wth a conpiler flag.
- microtherion 9y ago
  A simple case is the warning clang will generate for: int err = 0; if (err = f()) { } This is indeed a useful warning, as it's common to mistype == as = in this situation, but it's also absolutely correct code, and the idiom that silences the warning (surrounding with extra parentheses) does not change anything about the correctness of the code.
  - makapuf 9y ago
    A hint could be that you're initializing to zero a local just to overwrite it. Not an error or a warning but it could hint that you did not mean to, isn't it ?
    - microtherion 9y ago
      The initialization is just an example to show that err is a previously declared variable. The actual code could easily be different, but the warning is emitted on seeing the assignment in the conditional.
clhodapp 9y ago
Perhaps what we really want is a flag to cause the compiler to error for code that would produce undefined behavior and give warnings for the rest? Turning all warnings into errors is a great "worse is better" technique but it seems a bit too coarse-grained to me.
- eru 9y ago
  Alas, undefined behaviour in C++ and C is in general not that easily detected..
  - withzombies 9y ago
    It's true, but there's a few tools out there to help now, such as tis-interpreter (https://github.com/TrustInSoft/tis-interpreter https://github.com/TrustInSoft/tis-interpreter)
    - eru 9y ago
      Yes, an interpreter has a much better shot at detecting runtime undefined behaviour than a compiler. The whole point of undefined behaviour in C and C++ is to let the compiler cheat: ie a Java or Haskell compiler would have to take into account that (i < i + 1) can sometimes be wrong for native ints, and would have to prove that overflow can't happen in order to optimize this comparison away to True. Undefined behaviour in the standard frees C and C++ compilers from these obligations, and they can just assume overflow for signed ints won't happen. These shortcuts (plus a lot of smarts) make it feasible to write a fast optimizing compiler with the 1970s state of the art in static analysis.
  - clhodapp 9y ago
    Oh, to be sure! However, my claim is that if compiler authors are able to add more no-false-positives undefined behavior warnings over time, I kinda want those to "break" the build for my existing software... But if something is just a style check or creates false results, I'd rather the build be allowed to happen.
- mjevans 9y ago

mrguyorama 9y ago

Do you have an example I could take a look at? I'm actually not well versed in the C world

YSFEJ4SWJUVU6 9y ago
Unintended code (like having both arms of an if-else-statement execute the same action, or a duplicate condition in a logical expression) is sometimes perfectly valid as far as the standard goes. A double condition for example may simply be a result of poor refactoring, and thus the program even works as intended – however, the compiler cannot know that. That's why the helpful warnings flag those statements – -Werror then makes the compiler abort the compilation altogether on any warnings which is clearly not standard-compliant in cases like the one I outlined. The majority of the warning options showed in the article are intended to find unintended code (which can however perfectly defined if not intended behaviour as opposed to invalid, undefined behaviour). The very basic examples showed for those options also themselves do not contain anything that by itself would make the code not standard-compliant.
- dkersten 9y ago
  Well, the standard does not say that if you ask the compiler to flag potentially suspect code that it should compile successfully. That doesn’t make it non standard if you decide you do want your compiler to stop compiling when it encounters potentially suspect code and enable that mode wth a conpiler flag.
microtherion 9y ago
A simple case is the warning clang will generate for: int err = 0; if (err = f()) { } This is indeed a useful warning, as it's common to mistype == as = in this situation, but it's also absolutely correct code, and the idiom that silences the warning (surrounding with extra parentheses) does not change anything about the correctness of the code.
- makapuf 9y ago
  A hint could be that you're initializing to zero a local just to overwrite it. Not an error or a warning but it could hint that you did not mean to, isn't it ?
  - microtherion 9y ago
    The initialization is just an example to show that err is a previously declared variable. The actual code could easily be different, but the warning is emitted on seeing the assignment in the conditional.

clhodapp 9y ago

Perhaps what we really want is a flag to cause the compiler to error for code that would produce undefined behavior and give warnings for the rest? Turning all warnings into errors is a great "worse is better" technique but it seems a bit too coarse-grained to me.

eru 9y ago
Alas, undefined behaviour in C++ and C is in general not that easily detected..
- withzombies 9y ago
  It's true, but there's a few tools out there to help now, such as tis-interpreter (https://github.com/TrustInSoft/tis-interpreter https://github.com/TrustInSoft/tis-interpreter)
  - eru 9y ago
    Yes, an interpreter has a much better shot at detecting runtime undefined behaviour than a compiler. The whole point of undefined behaviour in C and C++ is to let the compiler cheat: ie a Java or Haskell compiler would have to take into account that (i < i + 1) can sometimes be wrong for native ints, and would have to prove that overflow can't happen in order to optimize this comparison away to True. Undefined behaviour in the standard frees C and C++ compilers from these obligations, and they can just assume overflow for signed ints won't happen. These shortcuts (plus a lot of smarts) make it feasible to write a fast optimizing compiler with the 1970s state of the art in static analysis.
- clhodapp 9y ago
  Oh, to be sure! However, my claim is that if compiler authors are able to add more no-false-positives undefined behavior warnings over time, I kinda want those to "break" the build for my existing software... But if something is just a style check or creates false results, I'd rather the build be allowed to happen.
mjevans 9y ago