lutro: fix a whoooole bunch of prototype warnings. #264
Conversation
jstine35
force-pushed
the
prototype-warns
branch
from
760dd5d to
c19cb84
Compare
Makefile
Outdated
| WARN_FLAGS += -Wno-unused-value | ||
| WARN_FLAGS += -Wno-unused-variable |
There was a problem hiding this comment.
I usually appreciate having these warnings, as it indicates places where issues could arise. Could we go through and fix those issues? Or are they specific to third-party libraries?
There was a problem hiding this comment.
Removed warning suppression. I'll just make a shell script to set WARN_FLAGS env on my end locally.
As for the warnings, they are primarily originating from 3rd party headers. Vorbis is the main offender. A couple of Lua and assertion macros are also sources. The warnings reported between gcc and clang actually differ wildly too, as well as across different versions of clang. It seems very inconsistent which compilers - and which versions of these compilers - judge unused values or variables as worth reporting. This is evidence that compilers are in some cases already trying to reduce the volume of warnings these tend to generate, and have yet to arrive at any consensus on what's good or right.
There was a problem hiding this comment.
Since they're third party, it does make things challenging. Is there a way to ignore them just for that code?
An interesting trivia of C99/C11 is that it isn't supposed to allow `()` for void functions. This is due to a classic rule of C language where `()` was actually a type of varadic, and matches any number of arguments. Thus, the use of either `(void)` or `(...)` is recommended for C programs to clearly differentiate them from the ambiguous `()` definition. (this doesn't apply to C++ code)
jstine35
force-pushed
the
prototype-warns
branch
from
c19cb84 to
f8861d3
Compare
|
Updated description to reflect reduced scope of changes. Warnings behavior is at compiler level is not modified. |
An interesting trivia of C99/C11 is that it isn't supposed to allow
()for void functions. This is due to a classic rule of C language where()was actually a type of varadic, and matches any number of arguments. Thus, the use of either(void)or(...)is recommended for C programs to clearly differentiate them from the ambiguous()definition. (this doesn't apply to C++ code)