5 ms·

Can you be more specific, maybe with an example of such code? I feel (rather strongly) that the language's standpoint is pretty clear, and that warnings are a

by unwind 5y ago

Can you be more specific, maybe with an example of such code? I feel (rather strongly) that the language's standpoint is pretty clear, and that warnings are a message of joy, the compiler is giving you an opportunity to fix a bug before it happens. Why is not "fixing the code" an option? If people don't understand the warning, and resort to "fiddling" to make it go away, that's a warning that there might be some training needed. :)

pornel 5y ago
A common case is an unused variable. It may be hard to avoid if macros/ifdefs are involved, or if it's an argument of a function that must match a predefined API. To "fix" such warnings people add a cast to void, self-assignment, or some other dummy code that makes compiler think it's "used", until you get a compiler with better data flow analysis that can see through the faux-use code. __attribute__((unused)) solves this properly, but technically it's a GNU extension. And it's just for this warning, not a general solution for hundreds of other warnings you may get. Other cases: • Implicit conversion warnings. This can happen due to platform's headers using slightly different types (e.g. disagreeing on signedness). You add an explicit cast, but now there's a third type involved, and if it wasn't the right type, you're worse off. • Tautological or side-effect-free expressions. Platform-specific code and macros can make them. You add more ifdefs, which is a hit on readability, and more opportunity to mess it up and break a platform you don't have CI for. • Cast to a type with a higher alignment. It is a common pitfall, and could cause UB, so it's good to be warned about. But if you've done required pointer arithmetic or aligned allocs, you need to be able to say "I know what I'm doing". You can't, apart from trying to obfuscate the code to confuse the compiler (and human readers too probably).
- unwind 5y ago
  That's a great list, thanks a lot. For the first case and third cases, as far as I know casting to void is the offical, supported, language-proper way to say "this value is not being used" so no compiler improvement should break that. The draft C18 standard says: If a function call is evaluated as an expression statement for its side effects only, the discarding of its value can be made explicit by converting the expression to a void expression by means of a cast and (in 6.3.2.2 Void): If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.) So that sounds like the proper solution, at least for those problems. Regarding the alignment, I haven't seen that warning I think. This SO answer [1] recommends casting via void *, but that might count as an "obfuscation"; I would count it as just that, a "I'm know what I'm doing"-statement. :) [1] https://stackoverflow.com/questions/33218873/how-to-properly-resolve-increase-in-pointer-alignment-with-clang https://stackoverflow.com/questions/33218873/how-to-properly...

by unwind 5y ago

pornel 5y ago

A common case is an unused variable. It may be hard to avoid if macros/ifdefs are involved, or if it's an argument of a function that must match a predefined API. To "fix" such warnings people add a cast to void, self-assignment, or some other dummy code that makes compiler think it's "used", until you get a compiler with better data flow analysis that can see through the faux-use code. __attribute__((unused)) solves this properly, but technically it's a GNU extension. And it's just for this warning, not a general solution for hundreds of other warnings you may get. Other cases: • Implicit conversion warnings. This can happen due to platform's headers using slightly different types (e.g. disagreeing on signedness). You add an explicit cast, but now there's a third type involved, and if it wasn't the right type, you're worse off. • Tautological or side-effect-free expressions. Platform-specific code and macros can make them. You add more ifdefs, which is a hit on readability, and more opportunity to mess it up and break a platform you don't have CI for. • Cast to a type with a higher alignment. It is a common pitfall, and could cause UB, so it's good to be warned about. But if you've done required pointer arithmetic or aligned allocs, you need to be able to say "I know what I'm doing". You can't, apart from trying to obfuscate the code to confuse the compiler (and human readers too probably).

unwind 5y ago
That's a great list, thanks a lot. For the first case and third cases, as far as I know casting to void is the offical, supported, language-proper way to say "this value is not being used" so no compiler improvement should break that. The draft C18 standard says: If a function call is evaluated as an expression statement for its side effects only, the discarding of its value can be made explicit by converting the expression to a void expression by means of a cast and (in 6.3.2.2 Void): If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.) So that sounds like the proper solution, at least for those problems. Regarding the alignment, I haven't seen that warning I think. This SO answer [1] recommends casting via void *, but that might count as an "obfuscation"; I would count it as just that, a "I'm know what I'm doing"-statement. :) [1] https://stackoverflow.com/questions/33218873/how-to-properly-resolve-increase-in-pointer-alignment-with-clang https://stackoverflow.com/questions/33218873/how-to-properly...