The Daily WTF: Curious Perversions in Information Technology

no laughing matter · 2014-07-28 Reply Admin

TRWTF: Claiming that declarations are always ordered alphabetically, when clearly they are not!

This is how to do it correct:

       context_option_type_bool                = 1,
       context_option_type_double              = 2,
       context_option_type_file_not_found      = 7,
       context_option_type_float               = 3,
       context_option_type_max                 = 7,
       context_option_type_string              = 4,
       context_option_type_uint32              = 5,
       context_option_type_uint64              = 6,
       context_option_type_unknown             = 0;

2014-07-28 Reply Admin

This representative line really just says it all:

assert(false && "Invalid context option specified.");

Arantor · 2014-07-28 Reply Admin

Article is passable levels of WTF. TRWTF is that the main page says '1 Comments' when it's simply @PaulaBean's comment on the subject telling us there's a post.

Anonymous · 2014-07-28 Reply Admin

I don't get it, why the two-space indentation after typedef, while others are 4-space indentation? Perhaps this is TRWTF?

tufty · 2014-07-28 Reply Admin

TRWTF is suggesting getopt() instead of boost::program_options when the article is clearly based on C++.

faoileag · 2014-07-28 Reply Admin

Arantor:
Article is passable levels of WTF. TRWTF is that the main page says '1 Comments' when it's simply @PaulaBean's comment on the subject telling us there's a post.

You forgot *frist* then!

RaceProUK · 2014-07-28 Reply Admin

tufty:
TRWTF is suggesting ```getopt()``` instead of ```boost::program_options``` when the article is clearly based on C++.

Which works wonders for those who don't have the Boost library installed :stuck_out_tongue:

2014-07-28 Reply Admin

anonymous:
This representative line really just says it all:
assert(false && "Invalid context option specified.");

No it doesn't.

The ANSI C assert function does not provide an argument for a message, but when the assert fires it does print out the expression that caused the assert failure.

The && "Something" is a very common way to ensure that there is some human readable description when the assert fails, so that you aren't left guessing what the hell happened.

The use of false is a very common way to force the assert to occur. It's usually used if you want a run time check that is in both release and debug builds, but still want to assert in debug builds to make it easier to find that something went wrong.

You could argue whether the assert itself was necessary, and you can argue whether the standard C assert function is TRWTF. But none of that is representative of the mess that is the rest of the code.

Arantor · 2014-07-28 Reply Admin

faoileag:
You forgot *frist* then!

Fuck frist. I am glad to be combo breaker.

tufty · 2014-07-28 Reply Admin

Yes, I know, I know.

I once had somebody seriously suggest using some bits of boost for a project I was doing. A project that was written in C, and which targetted a rather small Atmel µC.

Filed under: Why don't my damned <sarcasm> tags show up?

no laughing matter · 2014-07-28 Reply Admin

Anon:
The ANSI C assert function does not provide an argument for a message (...)

TRWTF!

2014-07-28 Reply Admin

Anon:
anonymous:
This representative line really just says it all:
assert(false && "Invalid context option specified.");
No it doesn't.

The ANSI C assert function does not provide an argument for a message, but when the assert fires it does print out the expression that caused the assert failure.

The && "Something" is a very common way to ensure that there is some human readable description when the assert fails, so that you aren't left guessing what the hell happened.

The use of false is a very common way to force the assert to occur. It's usually used if you want a run time check that is in both release and debug builds, but still want to assert in debug builds to make it easier to find that something went wrong.

You could argue whether the assert itself was necessary, and you can argue whether the standard C assert function is TRWTF. But none of that is representative of the mess that is the rest of the code.

It could be argued, somewhat convincingly I think, that:

if (something) assert(false && "something");

should be changed to:

assert(!something);

But you're basically right, so I'm really not going to argue the point of semantics.

nerd4sale · 2014-07-28 Reply Admin

For those unfamiliar with C, I recommend investigating getopt, the POSIX standard function for parsing command-line options.

There's the real WTF: why would anyone unfamiliar with C even **want** to investigate getopt? I'd wish I could go back to being unfamiliar with C.

antiquarian · 2014-07-28 Reply Admin

Cannot find cornify. Please advise.

RaceProUK · 2014-07-28 Reply Admin

tufty:
Why don't my damned <sarcasm> tags show up?

Use the HTML entities, and it'll work: <yaytag>

Nutster · 2014-07-28 Reply Admin

Will this even compile in a DEBUG environment? Those assert calls try to use a bool and a string as arguments to &&. Please tell me somebody did not overload that operator that way!

dkf · 2014-07-28 Reply Admin

Nutster:
Will this even compile in a DEBUG environment?

Compile? Yes. While they run, OTOH?

Steve_The_Cynic · 2014-07-28 Reply Admin

Argle. All those ::std::{thing} references make my teeth itch. What's wrong with just "std::{thing}" instead? (Yes, I know, leaving out the initial :: leaves the code open to sub-namespaces called std, but really, who does that, and can I strap whoever it is to the noisy end of my GAU-8?)

Arantor · 2014-07-28 Reply Admin

RaceProUK:
Use the HTML entities, and it'll work: <yaytag>

Yes, Discourse is so modern you have to escape your own entities!

chubertdev · 2014-07-28 Reply Admin

This is obviously low-level code for Python. The other types will be implemented later.

from __future__ import *

2014-07-28 Reply Admin

no laughing matter:
Anon:
The ANSI C assert function does not provide an argument for a message (...)
TRWTF!

Is this the frist time when C was TRWTF? Usually it's Java, PHP, VB, and of course Javascript -- they're all TRWTF by default, even before you write a single line of code.

2014-07-28 Reply Admin

facilisi:
no laughing matter:
Anon:
The ANSI C assert function does not provide an argument for a message (...)
TRWTF!
Is this the frist time when C was TRWTF? Usually it's Java, PHP, VB, and of course Javascript -- they're all TRWTF by default, even before you write a single line of code.

Is C the WTF when it's really a macro defined in one of the standard header files?

2014-07-28 Reply Admin

anonymous:
It could be argued, somewhat convincingly I think, that:
if (something) assert(false && "something");
should be changed to:
assert(!something);

So what? The code doesn't have

if (something) assert(false && "something");

The code tests something_else, and in a release build when the assert doesn't do anything the code goes somewhere else. Your change would make a WTF in a release build.

2014-07-28 Reply Admin

Aaron:

if (
    (string_context_option_lowercase.compare("1") == 0) ||
    (string_context_option_lowercase.compare("true") == 0) ||
    (string_context_option_lowercase.compare("yes") == 0))
{
    return_value = true;
}

So filenotfound and fılenotfound evaluate to false? What kind of bool is this?

2014-07-28 Reply Admin

piisawheel314:
Remy Porter:
(about as organized as organized crime).
I think you might be surprised. Organized crime is probably run better than most software houses.

I bet he wouldn't be surprised. In fact there's a better way to express how thoroughly organized this operation is and how much force is involved in imposing this organization, but the analogy would Godwinize this thread, preventing rational discourse.

2014-07-28 Reply Admin

Arantor:
Offers were made that couldn't be refused.

They should have done objection oriented programming, where programmers refuse each other's classes.

piisawheel314 · 2014-07-28 Reply Admin

(about as organized as organized crime).

I think you might be surprised. Organized crime is probably run better than most software houses.

Arantor · 2014-07-28 Reply Admin

Offers were made that couldn't be refused.

rafa1981 · 2014-07-28 Reply Admin

There is no such thing as strings in c. The characters between quotes evaluate to a const char * in this case, which can be bool tested for nullity.

The string is added to help clarifing the error message when the assert is triggered at runtime. The typical assertion error messages just show the file name, line number and the text passed to the assert macro ". So the author just hacks more text inside.

chubertdev · 2014-07-28 Reply Admin

rafa1981:
There is no such thing as strings in c. The characters between quotes evaluate to a const char * in this case, which can be bool tested for **nullity**.
The string is added to help clarifing the error message when the assert is triggered at runtime. The typical assertion error messages just show the file name, line number and the text passed to the assert macro ". So the author just hacks more text inside.

Leave math and division by zero out of this.

2014-07-28 Reply Admin

At least 2 memory allocations and object constructions, along with more than half a dozen function calls, just to do this?

 return !stricmp(argv[i], "1")
     || !stricmp(argv[i], "true")
     || !stricmp(argv[i], "yes");

P.S. the code in this WTF doesn't replace getopt(), even if you use getopt() you'd still need to parse the individual parameters to an option in various types (which is what this code is supposed to do.)

no laughing matter · 2014-07-29 Reply Admin

Norman Diamond:
(..) preventing rational discourse.

Preventing (...) discourse is always the right thing to do!

2014-07-29 Reply Admin

Norman Diamond:
Arantor:
Offers were made that couldn't be refused.
They should have done objection oriented programming, where programmers refuse each other's classes.

OK, I'll chime in: The REAL WTF is that responses to comments are shown, but the original comment isn't. So, either Arantor's comment was deleted, or it bled over from Discourse?!!

Captcha: plaga. Discourse is a plaga on both our houses.

2014-07-29 Reply Admin

Norman Diamond:
anonymous:
It could be argued, somewhat convincingly I think, that:
if (something) assert(false && "something");
should be changed to:
assert(!something);
So what? The code doesn't have
if (something) assert(false && "something");
The code tests something_else, and in a release build when the assert doesn't do anything the code goes somewhere else. Your change would make a WTF in a release build.

Yes it does. And the existing code is the WTF, not the change that I suggested.

if (context_option > this->vector_context_option_to_type_mapping.size())
{
   assert(false && "Invalid context option specified.");
   goto exit;
}

should all be replaced with:

assert(context_option <= this->vector_context_option_to_type_mapping.size());

(that's also way too fucking long, but that's another issue altogether)

There is NO reason for "assert...goto exit". That's its own WTF right there. No, if you disable asserts so that they don't do anything, you should STILL NEVER EXECUTE THE GOTO, BECAUSE YOU SHOULD NEVER GET TO IT IN THE FIRST PLACE.

In a test build, you should use assert to ensure that the application isn't about to blow up. The assert gives you specific information on what happened (which should've never happened) and where. Ever getting to an assert that is written to always fail means that a critical bug exists in your application. In a release version, the program silently "goes somewhere else" and ignores that critical bug. That is TRWTF.

If the original programmer wanted to gracefully return false when an invalid context option was specified (and, there could certainly be valid reasons for wanting to do that), using assert at all was simply inappropriate.

2014-07-29 Reply Admin

anonymous:
Norman Diamond:
anonymous:
It could be argued, somewhat convincingly I think, that:
if (something) assert(false && "something");
should be changed to:
assert(!something);
So what? The code doesn't have
if (something) assert(false && "something");
The code tests something_else, and in a release build when the assert doesn't do anything the code goes somewhere else. Your change would make a WTF in a release build.
Yes it does. And the existing code is the WTF, not the change that I suggested.

The original code has many WTFs, but your WTF is worse than theirs.

anonymous:

if (context_option > this->vector_context_option_to_type_mapping.size())
{
   assert(false && "Invalid context option specified.");
   goto exit;
}

should all be replaced with:

assert(context_option <= this->vector_context_option_to_type_mapping.size());

No it cannot be. In a debug build, your result is equivalent to the original. In a release build, the original does a "goto exit" but your code barges ahead and performs all kinds of garbage. Do you work for Microsoft?

anonymous:
There is NO reason for "assert...goto exit". That's its own WTF right there. No, if you disable asserts so that they don't do anything, you should STILL NEVER EXECUTE THE GOTO, BECAUSE YOU SHOULD NEVER GET TO IT IN THE FIRST PLACE.

YOU NEED TO LEARN THE FUCKING DIFFERENCE BETWEEN A DEBUG BUILD AND A RELEASE BUILD.

2014-07-30 Reply Admin

Norman Diamond:
The original code has many WTFs, but your WTF is worse than theirs.
anonymous:
if (context_option > this->vector_context_option_to_type_mapping.size())
{
   assert(false && "Invalid context option specified.");
   goto exit;
}
should all be replaced with:
assert(context_option <= this->vector_context_option_to_type_mapping.size());
No it cannot be. In a debug build, your result is equivalent to the original. In a release build, the original does a "goto exit" but your code barges ahead and performs all kinds of garbage. Do you work for Microsoft?

Um, no, THE EXISTING code barges ahead and performs all kinds of garbage. Except that it skips merrily past the part that would probably have shat itself and crashed, so the damage is likely to be more widespread and harder to figure out when it eventually does burst into flames.

In a release build, the code can never execute. It is an unreachable block of code, so it doesn't MATTER that the assert does nothing. You've TESTED it. Or were your customers supposed to do the alpha testing for you? In that case, better to leave the assertions enabled!

"goto exit" is never a safe alternative when your assertion does nothing. NEVER. At the very least you should have a runtime error check with a big warning "This should never happen, please inform the person who wrote this that there's a critical bug in this code".

A failed assertion should mean that there is a CRITICAL BUG: something that should never have made it out of testing. Assertions are NOT meant for runtime error checking. If you can simply sidestep the offensive block of code without fear of any bad things happening, then DON'T USE AN ASSERTION. You can use #ifdef and log something in your debug builds, if you want, but don't use an assertion.

A Team of One

Leave a comment on “A Team of One”