just another brick in the -Wall

[Pype.Clicker]

it's been a looong debugging session ... i had enfringed #1 commandment of the C programmer (thou shalt not follow thee NULL pointer) and it need *much* time to discover it.

btw, i've tried something new: the -Wall (enable all warnings) flag of GCC -- so far, i was believing that i needn't warnings, because warnings were boring and didn't give any valuable information.

Hah! how f00lish was i ...

GCC pointed out dozen of uninitialized variables, tons of function that actually returned unpredictable value (often used as a true boolean) and a few "wrong parameters" due to the use of undeclared functions ...

So much horrors .. i even wonder how my code have worked for so long ...

Be wise, guyz. Put your code in the -Wall brick by brick, and do not wait until nothing works to try that marvelous option ...

Then study your C language book until you understand exactly what the compiler is complaining about and only then fix stuff.

a small example is

Code: Select all

if (var=constructor()) { ... } else fail("cannot construct object");

construct i had in a lot of place ... i thought it was foolish to add a pair of parentheses and have

Code: Select all

if (( var=constructor() )) { ... }

just to make the compiler pleased ... until i found a line of code i had written myself a few monthes ago and couldn't remember whether it should be "x=y" or "x==y" ... Fortunately the complete operation wasn't too complex so with the comments i had already written, i could figure in this very case, "x=y" was correct, but pretty weird ... but it took me about half an hour to find out !

now that it's written (( x=y )) i hope it will be easier to get convinced that it's an affectation plus a "non-null" test rather than a comparison.


Hope my experience will help you ...

[Tim]

I couldn't agree more. A warning is just as bad as an error, unless you know fully why the warning was given and why it might be harmless in the situation.

You should always enable all warnings. If you get an error or warning, don't just fiddle with the code to shut the compiler up; for instance, don't just insert a typecast because that's what works. Find out why the compiler doesn't like your code, and do the right thing to fix it.

[Solar]

Amen.

One more - under Linux, I always encounter Makefiles that belch up tons of output. Which file is compiled with which options to which object file... with the occassional compiler warning thrown in for spice.

The problem is - the developer *might* (or might not...) know that this warning is OK. It leaves *me* with the eerie feeling that something is broken, and I don't even know what since, in those tons of output, the warning just whips past.

If you want to do your users a favor, make your (release) makefiles quiet, and free of "warnings that are OK", so the user actually *knows* when things are broken.

[Tommie.]

Or use lint to pick out fluff code to ensure it passes their stringent rules.....

Tommie/newbie_os_dsgnr

[Solar]

Sadly enough, lint doesnt work with C++... :'(