1 |
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote: |
2 |
> On 06/27/2010 01:47 PM, Enrico Weigelt wrote: |
3 |
> > * Nikos Chantziaras<realnc@×××××.de> schrieb: |
4 |
> > |
5 |
> >> Did it actually occur to anyone that warnings are not errors? You can |
6 |
> >> have them for correct code. A warning means you might want to look at |
7 |
> >> the code to check whether there's some real error there. It doesn't |
8 |
> >> mean the code is broken. |
9 |
> > |
10 |
> > In my personal experience, most times a warning comes it, the |
11 |
> > code *is* broken (but *might* work in most situations). |
12 |
> |
13 |
> That's the key to it: most times. Granted, without -Wall (or any other |
14 |
> options that tweaks the default warning level) we can be very sure that |
15 |
> the warning is the result of a mistake by the developer. But with |
16 |
> -Wall, many warnings are totally not interesting ("unused parameter") |
17 |
> and some even try to outsmart the programmer even though he/she knows |
18 |
> better ("taking address of variable declared register"). In that last |
19 |
> example, fixing it would even be wrong when you consider the optimizer |
20 |
> and the fuzzy meaning of "register" which the compiler is totally free |
21 |
> to ignore. |
22 |
|
23 |
The compiler is not totally free to ignore the register keyword. Both |
24 |
the C and the C++ standards require that the compiler complain when |
25 |
taking the address of a register variable. Other compilers will issue a |
26 |
hard error for it. Fixing the code to not declare the variable as |
27 |
register would be the correct thing to do. |
28 |
|
29 |
Make sure you *understand* warnings, and then you can decide whether to |
30 |
fix the code, if there is anything to fix, or to ignore. |