| 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. |
Archives