Comment On Another Brick in the Wall

Maybe getIpv4Address() sets some global variable, and the constructor for QString reads that variable....

I hope he's being sarcastic when he bashes -Wall... We actually do use it and find it very useful... The annoying thing is when people start using -Wall -Werror...

The guy was in hurry, forgot to fill the string before calling return.

Um, how did any of this work?

vt_mruhlin:

Maybe getIpv4Address() sets some global variable, and the constructor for QString reads that variable....

Sure thing...then it tries to figure out what kind of value it needs to process and then calls hostname functions to resolve the IP address to the according DNS. Tricky bastard, the compiler will never know the truth.

captcha: Q for quaint?

GettinSadda:

Um, how did any of this work?

It probably didn't. Or at least not well, or reliably.

Anyways, I'm a firm believer in always compiling with highest levels of warnings on and treating warnings as errors. Saves you from the stupid stuff.

Kozak:

I hope he's being sarcastic when he bashes -Wall... We actually do use it and find it very useful... The annoying thing is when people start using -Wall -Werror...

The real WTF is that the -Wall option doesn't always work with Visual Studio 2005. I just tried compiling a vb.net AND a c# application with -Wall for example and neither of them got added to the windows firewall list. Then again I am running norton antivirus too, so who knows.

Never mind my last post. I was thinking of some other command.

Remeber kids: warnings are errors. Keep your builds clean. Always use protection.

Kozak:

I hope he's being sarcastic when he bashes -Wall... We actually do use it and find it very useful... The annoying thing is when people start using -Wall -Werror...

Where does he bash -Wall?

Wouldn't that code get a warning about an uninitialized object? I don't know how Qt handles initialization of objects, but that looks to me like an uninitialized reference

i actually found the same kind of stuff in some embedded system code. the way to avoid the compiler warning was just 'different':

int doSomeStuff( int a, int b, int c )

{

    int result;



    a = a;

    b = b;

    c = c;



    // do some complex computation that does not involve any of the 3 variables and store the result



    return result;

}

i loved the way they declared parameters, did not use them at all but obviously fixed the compiler warning instead of just removing the parameters. in the system involved, removing those unused parameters would have been no problem at all...

how about this forum software huh? IS THIS THE BIGGEST PIECE OF CRAP OR WHAT????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

It's C++ and Qt, and he didn't declare it as a pointer. So it is initialized, but has, probably, an empty string for the value.

rien:

i actually found the same kind of stuff in some embedded system code. the way to avoid the compiler warning was just 'different':

int doSomeStuff( int a, int b, int c )

{

    int result;



    a = a;

    b = b;

    c = c;



    // do some complex computation that does not involve any of the 3 variables and store the result



    return result;

}

i loved the way they declared parameters, did not use them at all but obviously fixed the compiler warning instead of just removing the parameters. in the system involved, removing those unused parameters would have been no problem at all...

I always found it more obvious to throw the value away (AKA "cast it into the void").

(void) a;

But I've also seen compilers that complain about this idiom.

More importantly, what does

$ bash -Wall

do?

Bourne:

More importantly, what does

$ bash -Wall

do?

When I bash Wall, it's usually for creating Perl, a programming language that makes me want to bash the wall with my head.

speaking of wtf's:

how about this forum software huh? IS THIS THE BIGGEST PIECE OF CRAP OR WHAT????...???????

If you don't like it, simply don't use it!
Go away and don't come back!

chris:

It's C++ and Qt, and he didn't declare it as a pointer. So it is initialized, but has, probably, an empty string for the value.

Indeed, and the function (or is it a method?) is still a WTF since it still isn't doing what it ought to. Leastways, not unless there's some unholy coupling of the ipv4addr lookup code and QString in there, which is probably not the case (Qt being not quite that insane even from the PoV of its detractors.)

Usually changing the prototype to:

int doSomeStuff( int /*a*/, int /*b*/, int /*c*/ )

is better. Then the compiler doesn't generate any code to optimise away later.

Why would you do this anyway? Well if this function is an implementation of a standard function like:

int Add(int a, int b)
int Sub(int a, int b)
int Div(int a, int b)
int Add3(int a, int /*b*/) <- b not used in this function

The functions can all be added to an array of function calls and then used as a lookup.

Sometimes you cannot just remove parameters: for example if your class implements an interface; some other implementations might need this parameter. But i would supress this warning instead of fooling the compiler with a = a stuff.

zip:

Where does he bash -Wall?

Code Monkey angry! Code Monkey smash -Wall!

But Wall doesn't use bash, he wrote perl....

captcha: bathe.. what programmers do fairly irregularly

NS:

Usually changing the prototype to:

int doSomeStuff( int /*a*/, int /*b*/, int /*c*/ )

is better.

Pedantry, but changing the prototype (declaration) does nothing. You need to do the commenting on the variables in the function definition i.e. the one with the curly braces afterwards.

In the original post I was wondering what 'dns' stood for. How about

Does
Nothing
Surprisingly

Actually, the joke is the opposite of this story.

A programmer is smoking a cigarette, and his friend says to him "Why are you doing that? Didn't you see the warning on the package that says those can cause cancer?"

The programer replies "I only care about errors, not warnings."

ailivac:

Actually, the joke is the opposite of this story.

A programmer is smoking a cigarette, and his friend says to him "Why are you doing that? Didn't you see the warning on the package that says those can cause cancer?"

The programer replies "I only care about errors, not warnings."

Back when I smoked, I always smoked the ones that warned about low birth weight, ect. Seeing as how I am male that didn't concern me. Now the ones that warned about cancer and such I stayed away from.

-wall is your friend. PCLint is your best friend.

MET:

In the original post I was wondering what 'dns' stood for. How about

Does
Nothing
Surprisingly

Dummy
New
String

I never seem to run into anyone that actually understands what warnings are. Half of the people think that warnings are worthless and should be ignored (I guess 'it compiles it has to work!' is in this group) while the other half think that warnings should be eliminated (-Wall -pedantic and throw casts everywhere until it shuts up without actually looking at what is going on).

It makes me cry a little.

batasrki:

Wouldn't that code get a warning about an uninitialized object? I don't know how Qt handles initialization of objects, but that looks to me like an uninitialized reference

This is C++. The string is created on the stack. It is initialised by its ctor.

This method doesn't surprise me - I'm sure the developer thought "I'll just write a method to get the hostname from an IP" and was about to fill in the method body when (s)he found out what sort of work was actually involved in doing this (and that you can't actually do it with 100% certainty)... but then got distracted and didn't delete it.

Rik Hemsley:

but then got distracted and didn't delete it.

Actually, it might have been me...

diaphanein:

GettinSadda:

Um, how did any of this work?

It probably didn't. Or at least not well, or reliably.

Anyways, I'm a firm believer in always compiling with highest levels of warnings on and treating warnings as errors. Saves you from the stupid stuff.

Sometimes you have to live with a warning. One example is when you're using a enumerated type to show the next programmer what mode the firmware is in. You can't send the mode as text without a huge amount of overhead, so you have to "mix enumerated type with integers".

Other times, you'll get a "condition always true" error for your superloop:

do{

//most of your code lives here

}while(true);

Why would yo do that, you ask? You'd do that on an embedded chip without an RTOS.

Put comments on the line so you remember why you're accepting the warning and so the next guy knows that he should spend no time trying to "solve" the warning. And whatever you do, don't turn off the warnings for those lines. I've seen people do that, and I think that's insane.

Most of the time, the compiler is trying to save your butt. "Assignment inside conditional expression." comes to mind.

So you can live with some errors, as long as you know why they are there and can explain why you're living with the error.

jethrotull:

Sometimes you cannot just remove parameters: for example if your class implements an interface; some other implementations might need this parameter. But i would supress this warning instead of fooling the compiler with a = a stuff.

unfortunately, the unused variable warning may be the only warning generated by this same compiler: it does not even complain about using a variable before it has being assigned. it is the crappiest compiler i've ever seen (or maybe i have to read the doc, it was Texas Instruments IAR Workbench).

for the code i submitted, that was pure stand-alone function in C, no interface to comply to... and it was (and is still) a single developper small project. when i took over the project, i simply changed the signature, changed the 1 or 2 places the function was called, and re-compiled.

Kozak:

I hope he's being sarcastic when he bashes -Wall... We actually do use it and find it very useful... The annoying thing is when people start using -Wall -Werror...

gcc has a shorthand for that it's '-Wfascist'.

(I kid, I kid, we use -Werror on all automated builds, and if you cause an automated build to fail, all the other engineers beat down the gates of your cube with coffee cups and white-board markers.)

Ok, now I really must return to modifying boot scripts on an embedded device with ed.

Jeff

I hate CodeSODs like this; you know there's at least a half dozen other functions you could add on top that would be just as funny. Ten lines of BS for a 4-line function feels like cheating. I guess TDWTF is now all about bite-sized chuckles that are quickly forgotten, instead of the legendary functions from the early days.

Cthulhu:

The real WTF is that the -Wall option doesn't always work with Visual Studio 2005. I just tried compiling a vb.net AND a c# application with -Wall for example and neither of them got added to the windows firewall list. Then again I am running norton antivirus too, so who knows.

The correction that followed doesn't make this any less hilariously surreal. =D

rien:

i actually found the same kind of stuff in some embedded system code. the way to avoid the compiler warning was just 'different':

int doSomeStuff( int a, int b, int c )

{

    int result;



    a = a;

    b = b;

    c = c;



    // do some complex computation that does not involve any of the 3 variables and store the result



    return result;

}

i loved the way they declared parameters, did not use them at all but obviously fixed the compiler warning instead of just removing the parameters. in the system involved, removing those unused parameters would have been no problem at all...

Perhaps they were trying to fit the stack to a certain size :-P

rien:

in the system involved, removing those unused parameters would have been no problem at all...

The project I'm on now used to use a very slow compiler, and the full build of the system would take over 24 hours on the systems we had. So touching a commonly used header file was avoided at all costs by some people. Obsolete parameters were commonly left in place.

"The Real WTF": Someone submitted a daily WTF bashing the practice of *not* ignoring warnings, and it actually got posted instead of laughed right out of the queue.

rien:

i actually found the same kind of stuff in some embedded system code. the way to avoid the compiler warning was just 'different':

int doSomeStuff( int a, int b, int c )

{

    int result;



    a = a;

    b = b;

    c = c;



    // do some complex computation that does not involve any of the 3 variables and store the result



    return result;

}

i loved the way they declared parameters, did not use them at all but obviously fixed the compiler warning instead of just removing the parameters. in the system involved, removing those unused parameters would have been no problem at all...

I'll tell you maybe why they didn't remove the parameters: to do so they'd have to go and modify all the places that called that function. Some of those places fixed then might result in their *own* unused parameter variable warnings that need to have fixes propagated. So a quick low-risk change to one function in one file to remove an annoying warning now becomes a multi-file odyssey with correspondingly higher risks and test requirements.

I got clobbered once in a similar way: I needed to change a few high level functions to use const for certain parameters that they don't/shouldn't change, but then I was obligated to make similar fixes to dozens of lower level functions as the const-ness needed to propagate down the call chain (all of which legacy code was not const-correct).

rien:

in the system involved, removing those unused parameters would have been no problem at all...

Doh! I somehow missed this line when I read the post.

foxyshadis:

Ten lines of BS for a 4-line function feels like cheating. I guess TDWTF is now all about bite-sized chuckles that are quickly forgotten, instead of the legendary functions from the early days.

I kinda like the short ones. With a function that's a page long, you can easily understand that someone might choose to leave it alone, or not spot its utter brokenness. Whereas with something as simple as this, the brokenness is not so easily explained.

Other times, you'll get a "condition always true" error for your superloop:

To avoid that, use for(;;). This idiom often used to be #defined as FOREVER, but is clear enough by itself. HTH+HAND.

Instead of a = a etc you can just get rid of the unused variables thusly:

delete (int *)&a;
delete (int *)&b;
delete (int *)&c;

Since they're deleted you won't have to worry about them anymore.

themagni:

Put comments on the line so you remember why you're accepting the warning and so the next guy knows that he should spend no time trying to "solve" the warning. And whatever you do, don't turn off the warnings for those lines. I've seen people do that, and I think that's insane.

Why is it insane to turn off a warning for that line? Its more sane to spew out warnings to the developer that he should ignore? Or turn off the warning for that one line?

Its insane NOT to turn the warning off. You are already willing to except that warning. If that warning is going to fire, on that same line, for a completely different reason. You will never know, because you are ignoring the warning. If you are going to ignore the warning, then really ignore it and make it go away. That way you won't miss other warnings.

phaedrus:

Kozak:

I hope he's being sarcastic when he bashes -Wall... We actually do use it and find it very useful... The annoying thing is when people start using -Wall -Werror...

gcc has a shorthand for that it's '-Wfascist'.

(I kid, I kid, we use -Werror on all automated builds, and if you cause an automated build to fail, all the other engineers beat down the gates of your cube with coffee cups and white-board markers.)

Jeff

Heh, A good friend of mine has balloons that say "I broke the build". he attaches them to the cube/desk of whomever checked in the bad code.

A common problem I run into in C is that I use arrays of function pointers as a poor man's dispatch table. Since all of the operations in the table have to use the same function prototype you sometimes end up with unused arguments for certain functions. A long time ago I stumbled upon this macro in some of the Quake(?) source code:

#define UNUSED(x) ((x) = (x))

Needless to say, I use it a lot. That being said, I've never

UNUSED()

all of the arguments to a function...

*shrug*

I got clobbered once in a similar way: I needed to change a few high level functions to use const for certain parameters that they don't/shouldn't change, but then I was obligated to make similar fixes to dozens of lower level functions as the const-ness needed to propagate down the call chain (all of which legacy code was not const-correct).

Kind of makes me wish for a sort-of const keyword. Maybe "mostly const"?

chrismcb:

themagni:

Put comments on the line so you remember why you're accepting the warning and so the next guy knows that he should spend no time trying to "solve" the warning. And whatever you do, don't turn off the warnings for those lines. I've seen people do that, and I think that's insane.

Why is it insane to turn off a warning for that line? Its more sane to spew out warnings to the developer that he should ignore? Or turn off the warning for that one line?

Its insane NOT to turn the warning off. You are already willing to except that warning. If that warning is going to fire, on that same line, for a completely different reason. You will never know, because you are ignoring the warning. If you are going to ignore the warning, then really ignore it and make it go away. That way you won't miss other warnings.

One day, you'll forget to turn the warnings back on. Then, you'll think about this post and say, "Ohhhhh. That's what that damned fool was blabbering about."

Let's say you do this:

#disable warning "condition always true"

do

{

 //codity code code

}while( true );

#end disable <--imagine forgetting this line

                                            |

void someFunction( )                        |

{                                           |

  if( 1 ) //debug: checkPin( foo )          |

  {                                         |

    //oops, I'm running. <------------------|

  }

}

The one failing of the Internet is that it is hard to detect sarcasm. For the love of God, you WERE being sarcastic, right? Right?!

themagni:

chrismcb:

Why is it insane to turn off a warning for that line? Its more sane to spew out warnings to the developer that he should ignore? Or turn off the warning for that one line?

One day, you'll forget to turn the warnings back on. Then, you'll think about this post and say, "Ohhhhh. That's what that damned fool was blabbering about."

Agreed that that's an issue, but I'm siding with chrismcb. If you have a program that produces warnings in its output, you're less likely to spot if a NEW warning appears.

As long as you only have a couple lines producing the warnings, it's probably better to turn them off since the warning directives will be very localized. If it's more than a couple lines (like your example) it's a more difficult problem. I would think this might be justification for breaking the offending lines into another function.