> 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.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
