Ahh, I see, the actual fix is not the
variable, but the wrong order of operands in the assembly, I
missed that.
Ah, I thought it was just a side note. You rarely miss stuff like
that ;)
But the additional prototypes are still
pointless ;-)
Btw, I'm all for enabling extra warnings, but the following ones
seem not very useful or will probably create a lot of noise:
-Wunused-but-set-variable (we have this in many places)
-Wmaybe-uninitialized (gives too many warnings,
since initializing something by passing it to a function cases
this warning)
-Wmissing-prototypes (in the kernel no
functions are declared static (wrong IMO, but that's how it
is), which will lead to many warnings)
-Wmissing-declarations (see above)
-Wcast-align (explicitly casting to a
higher alignment can be useful and there is no other way to
avoid this warning)
-Wwrite-strings (I fear that we don't
always use the const modifier properly to allow this)
-Wuninitialized is already implicitly defined by -Wall
The following additional warnings seem to be reasonable by a quick
glance:
-Wframe-larger-than=
len / -Wstack-usage=
len
(at least for kernel mode code)
-Wbad-function-cast
-Wsign-compare (enabled on MSVC by default)
-Wsign-conversion
-Wlogical-op
-Waggregate-return
-Winvalid-pch
NP, we need then to decide on the new set of warnings (that brings
more benefits without creating noise/pointless diagnostics), fix the
revealed issues, and after we're done, we proceed permanently with
the set, so that the future check-ins would be subject to it.
Fortunately, GCC has the same concept of disabling warnings for a
code block
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html) so we
may use that if needed, in order to keep warnings that have just a
few pointless places.
Sounds like a plan ?
Regards,
Amine.