Re: Pioneer DVR-106D issues
> >-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
> >-fno-common -mpreferred-stack-boundary=2 -march=pentium3
> >-fomit-frame-pointer
>
> In the Schily makefile system (Developer set up) these warning options are
> used:
>
> CWOPTS= -Wall -Wtraditional \
> -Wshadow -Wmissing-prototypes -Wstrict-prototypes
>
> -Wtraditional more and more created problems with GCC-3.x
-Wtraditional clearly does not fit in Linux kernel makefiles - the
kernel uses ISO C constructions extensively.
So -Wshadow and -Wmissing-prototypes might be worth trying. I did try
them both (compiling 2.6.0, the latest stable kernel, with allmodconfig
- i.e. all drivers compiled as modules, except rebuilding Adaptec
firmware which I have no tools for and except kernel debug info since it
generates HUGE output files and I was running out of disk space) and
compared the build logs. -Wshadow gave 5 warnings in build tools
(firmware image generation and conversion etc) and -Wmissing-prototypes
gave 57 warnings but also only in build tools (documentation generation,
module generation, dependency generation, kernel symbol table
generation, console character map generation, initial ramfs generation,
ATM firmware image generation and x86 boot image generation). No single
additional warning in kernel code itself!
So adding these warning options would improve the build tools but not
the kernel itself (the build tools obviously work, dependency generation
is the only one that could theoretically cause yet undetected problem in
the real kernel). Adding them might still be worth it - _IF_ I clean the
warnings first. Will see if I get time for this.
So we have come up with no added warnings in the kernel code itself.
I am going to try -Wcast-align next on sparc-linux since it has helped
me several times in userland Sparc development.
> May be the problem is that there just too many false warnings so people
> did oversee the real bugs.
I would not say so, when compiling my normal kernel (drivers for all
the hardware that I own plus all USB drivers) with many hundreds
of files, I see about 3-4 warnings scroll by, and they are easily
noticed.
> >other parts of the kernel, IDE code and drivers use strongly typed
> >function pointers everywhere. Vast mayority of function parameters are
> >also strongly typed for any non-atomic types. The only functions I found
> >that have void* arguments that are not IO addresses are the following:
> _You_ are looking at the wrong places :-(
>
> The important things are called via function pointers that are in
> a structure...
Please reread what I said. All _function pointers_ (inside structs) are
strongly typed. See include/linux/ide.h yourself if you do not believe!
In addition to this, the majority of other functions have prototypes
with strongly typed arguments (except the functions I showed and some
I/O address parameters).
Frohe Weinachten!
--
Meelis Roos (mroos@linux.ee)
Reply to: