Hi Paul,
Thanks for your feedback.
> > an empty
> > function argument list (in a function definition!) is equivalent to (void).
>
> It's not equivalent in C, since (void) gives us extra compile-time type
> checking that an empty arglist does not. For example, there is no
> type error (and no GCC diagnostic) in this C code:
>
> int f () { return 0; }
> int main (void) { return f (1); }
>
> whereas there would be a type error if the () were replaced by (void).
It is true that there is an error if we write (void) instead of ().
But "gcc -Wall" produces a warning for
int f () { return 0; }
int main (void) { return f (1); }
namely:
f.c: In function 'main':
f.c:2:3: warning: call to function 'f' without a real prototype
f.c:1:7: note: 'f' was declared here
whereas it produces no warning for
int f () { return 0; }
int main (void) { return f (); }
Since I use -Wall for all compilations anyway, there is no benefit for
me in -Wstrict-prototypes or -Wold-style-definition: -Wall warns about
precisely the dangerous cases, whereas -Wstrict-prototypes and
-Wold-style-definition also warn for harmless code.
Additionally, by your explanation of how () differs from (void), the
'main' function is better declared as () not (void) - since crt0.o calls it
with two arguments. But -Wstrict-prototypes and -Wold-style-definition
give me a warning each time I write
int main () { ... }
> > I also won't use -Wunused-macros since it produces warnings that are
> > pointless
> > to fix:
> >
> > printf-frexp.c:63:0: warning: macro "L_" is not used
> > tempname.c:70:0: warning: macro "__open64" is not used
> > tempname.c:72:0: warning: macro "__xstat64" is not used
> > fnmatch.c:171:0: warning: macro "STRCOLL" is not used
> > fnmatch.c:199:0: warning: macro "STRCOLL" is not used
> > ...
>
> The first warning I'll grant you (though surely it is easy to work around)
Here I would have to conditionalize a macro because it happens to be unused
if a particular #if cascade is taken.
> but I don't see why the next four warnings are pointless to fix
These are in code that we borrow from glibc. We want to minimize the
differences to the original glibc code. Removing these macro definitions
would hamper future merges.
> > Even -Wshadow fires back unreasonably:
>
> This may be taste, but I don't find that warning unreasonable,
> as a local (yn) is shadowing a global (yn).
I would find it useful to have different warning options, one for
the shadowing of local variables or parameters, and a different one
for global entities. Getting a warning for each variable called
'y0', 'y1', 'exp', or 'index' is so annoying.
Bruno
--
In memoriam Kerem Yılmazer <http://en.wikipedia.org/wiki/Kerem_Yılmazer>
