The Daily WTF: Curious Perversions in Information Technology

da Doctah · 2013-04-10 Reply Admin

Norman Diamond:
da Doctah:
just me:
markfiend:
A former colleague was fond of if($boolean == TRUE) ...
Very useful pattern in C, in conjunction with: #define TRUE 0 #define FALSE 1
We used to do this (or the equivalent) in every PL/1 program, plus: #define NO 0 #define YES 1 #define OFF 0 #define ON 1 #define NO_ERROR 0 #define DOOMSDAY 0
Brillant. I was about to ask about the inconsistency between TRUE and NO, and between FALSE and ON, etc. But then I figured out you did that intentionally, because unmaintainability == job security.

No, it's "just me"s bizarre little C-ism that doesn't make sense. TRUE should be 1 and FALSE should be 0, or '1'b and '0'b as the only native versions are written in PL/1.

The others are likewise defined as bit-strings of length one, except for NO_ERROR, which is an int (spelled "fixed bin(31)") to distinguish it from all the possible non-zero return codes, positive and negative, that might otherwise occur.

Steve The Cynic · 2013-04-10 Reply Admin

not Tye:
"return 0; // meaning, success, which is brain-dead stupid"
While I agree. I understand the reason. There can be only 1 success value, but you may want to return any number of non-success values.

Go read about S_FALSE. Like S_OK, it is a success return from a COM/DCOM invocation/function call. Unlike S_OK, it is not zero.

It is the spawn of any number of very diabolical entities, if you believe in such things. Well, even if you don't believe in devils, it is the spawn of any and all of them, all at once.

2013-04-10 Reply Admin

n_slash_a:
faoileag:
EuroGuy:
flop:
Ever heard of ECC, bit errors, gamma rays, bad RAM, bugs in the CPU, and so on?
If every conditional statement in your code covers for the possibility of bad RAM, I don't want to see your code - ever.
Not every. You only need to do this with switch-statements. And yes, with switch-statements, a default branch is a sensible thing to have. Some coding styles even mandate them :-)
I work the in the GPS field for airplanes ... that an accidental bit flip condition is covered defensively

I was thinking more in terms of everyday programs like Office, Firefox, Smartphone Apps...

Of course in the aviation industry you program defensively! Although so far I thought that this would be handled by redundant, independant and developed-by-different-teams systems where truth is something along the line of a majority vote.

Programming defensively in just one application can of course be done, but I still have to see the code for an application where every variable is tripled (isAdmin1, isAdmin2, isAdmin3) and truth is determined by majority vote in case a bit-flip happens (isTrue(isAdmin1,isAdmin2,isAdmin3)).

2013-04-10 Reply Admin

switch ( isOk ) { case true: // something break; case false: // something else default: // wtf ! }

But the real WTF is: Who the hell makes a system where switch on boolean is even possible?

PleegWat · 2013-04-10 Reply Admin

I specifically do not include default cases when I'm switching on an enum. The compiler will give a warning if I'm not covering a possible enum value in the switch, which will vanish if a default case exists. And any uninitialized variable warnings can be worked around by initializing the variable before the switch, or adding an error return after.

This is C, so that error return may indeed be hit.

chubertdev · 2013-04-10 Reply Admin

[image]

that is all

2013-04-10 Reply Admin

QJo:
Not a WTF, merely an idiosyncrasy based upon a rigorously enforced house style. I'd have absolutely no problem if I were to see this in code maintained by my staff; it doesn't even require a comment, beyond an indulgent chuckle at what cards they all are.

Your rigorously enforced house style is stupid. Please tell us where you work so we can avoid it.

2013-04-10 Reply Admin

n_slash_a:
I work the in the GPS field for airplanes, if you are in an airplane on final approach, I bet you would like to know that an accidental bit flip condition is covered defensively and not have the airplane think it is suddenly at 1000 feet when it is really at 100 feet.

I would have thought you would mitigate this with hardware solutions(e.g. ECC) and/or redundant systems (with voting, as someone has already mentioned). It would seem impossible to guard against all bit flips in software, as a bit flip could change the program flow itself.

2013-04-10 Reply Admin

d.k.ALlen:
I prefer to simply say: if ( some_bool_expr ) {}
However, if I am in the middle of code generated by unix-weenies who have brought their thrice-cursed scripting skillz over to c/c++ (which happens frequently), I explicitly do:

if ( some_bool_expr == true ) {}

because the existing code will be littered with:

return 0; // meaning, success, which is brain-dead stupid

and the following corresponding wonderful bits:

if ( some_stupid_function() ) { error_handling_code }

I guess the real WTF is allowing anyone who returns 0 for success, anywhere near a real compiler.

(/over-the-top-pet-peeve-posting)

C++ code generally returns 0 on success. And there's a very good reason for that -- you can only return an integer, so you have 0 for success and 1-2^32 (or however big your system makes an int) for failure conditions. Particularly in the days when memory was small as any error message you print needs to be stored in memory somewhere -- instead of a bunch of print statements and strings you just return one integer. But even without that, when doing batch scripting it's very nice to be able to just compare one return value to check for specific errors rather than needing to iterate through the entire program's output.

The alternative is to return 1 on success and 0 on failure and have no idea what that failure is...or to return 1 on success and some other values that ALSO evaluates to true on failure.

I will agree though that this is sometimes carried over to places where it just doesn't make sense. At my job we have things like a database field named 'x_IS_VALID' that is 0 if the thing is valid, 1 otherwise. Always hell to figure out what that's doing, because then you get stuff like if( IS_VALID ) { // code to handle if it ISN'T valid }

2013-04-10 Reply Admin

anonymous:
Wow. I'm surprised with all the utterly amazing coders here that nobody seems to understand the concept of future-proofing your code.
You are typically one of many maintainers. You are typically not the last maintainer. Always having a default case in a switch statement, even if it is impossible when you write the code, allows you to log an error if someone else changes something that makes it possible.

For example, if you have an enum where all the cases are covered (as mentioned earlier) and somebody who is unaware of the particular switch statement you wrote adds a new value to the enum but doesn't extend the switch statement, then you typically want it to result in an error message. Ignoring this possibility makes it easier to introduce bugs. Take, for example, the following pseudocode:

foo.h-ish:
enum WORD { fizz=0, buzz, bang };
bar.pseudoc:
...
WORD w = ...;
int i;
switch(w) {
  case fizz: i=0; break;
  case buzz: i=5; break;
  case bang: i=17; break
}
...
If Sum Dum Guoy adds "thwomp" to WORD, but doesn't modify the switch, then i will be undefined. This is typically A Bad Thing(tm). If there were a default case that generated an error, then testing could catch what the developer did not.

Ah, but I forget, everyone who visits TDWTF writes perfect code, and works in shops where everyone writes perfect code, and only perfect coders are hired, so this could never happen in your world.

Or, you could not have a default, and catch it with a compile time warning (in most modern compilers). In case someone forced an out of range value to w (which would be grounds for taring and feathering said developer), initializing i would be a good mitigation.

2013-04-10 Reply Admin

da Doctah:
just me:
markfiend:
A former colleague was fond of if($boolean == TRUE) ...

Very useful pattern in C, in conjunction with:

#define TRUE 0 #define FALSE 1

We used to do this (or the equivalent) in every PL/1 program, plus:

#define NO 0 #define YES 1 #define OFF 0 #define ON 1 #define NO_ERROR 0 #define DOOMSDAY 0

That last one was for the benefit of loops that were supposed to continue indefinitely, ending only when some external force shut down the program they appeared in, so:

do until (DOOMSDAY)

I was working on a program recently where sale prices have start and end effective dates. If a sale is good indefinitely, the programmers were putting in end dates a hundred or more years in the future ... but each time someone came across this situation, they picked a new date. So some sales end in 2100, others in 3000, others in 2199, etc etc. I found the inconsistency annoying, so I created a static variable I called "DOOMSDAY" and set it to 12/31/2999. Now I'm changing all the far-futures to use DOOMSDAY.

If this program is actually still in use 986 years from now, I guess someone will have to update this. But I think it's a safe bit that I will no longer be working here.

2013-04-10 Reply Admin

If I have to forward an exception, I like to call it "up". That way I can write:

catch (Exception up)
{
  if (we_can_recover())
  {
    handle_it();
  }
  else
  {
    throw up;
  }
}

2013-04-10 Reply Admin

Arkady:
My C++ compiler throws a warning if a switch statement has no default case, even if the default case is impossible to hit (e.g. the input is an enum and every possible case is covered.)

Even if the input is an enum, the variable is just an int so it can have values outside of the list, so you still need the default clause to catch that error condition.

2013-04-10 Reply Admin

How about "If no switch case matches, do nothing". That sounds like the sort of warning I would turn off.

Kuba · 2013-04-10 Reply Admin

Arkady:
My C++ compiler throws a warning if a switch statement has no default case, even if the default case is impossible to hit (e.g. the input is an enum and every possible case is covered.)
Maybe the coder wants their code to run without warnings?

Your C++ compiler's team never heard of OCAML or Pascal. Oh, nevermind, go on.

2013-04-10 Reply Admin

faoileag:
Of course in the aviation industry you program defensively! Although so far I thought that this would be handled by redundant, independant and developed-by-different-teams systems where truth is something along the line of a majority vote.

Majority vote would be a killer. In the first space shuttle, 4 computers wanted to do one thing and 1 computer wanted to do something else. That was before launch so they scrubbed it and figured out that the 1 was right. If it happened in space a more suitable response would be to fall back to simpler bulletproof code and see if they all agree, or intervene by humans like on Apollo 13.

2013-04-11 Reply Admin

urza9814:
C++ code generally returns 0 on success. And there's a very good reason for that -- you can only return an integer, so you have 0 for success and 1-2^32 (or however big your system makes an int) for failure conditions. ...

See my subsequent comment for my answers to the points you raised (some of which I clipped). I do have to ask, what do you mean by 'C++ code'?

Neither c++ nor c languages mandate or specify returning anything to indicate success or failure. It is convention to return 0 from main upon success, as that is where the program meets the shell. The shell likes to see 0 for success, which was where we started this whole discussion.

There are some functions in the standard c library which return 0 for success, and probably as many (or more) which return 0 for failure. This illustrates (again) my point regarding unix weenies - it was unix weenies who invented c.

Nonetheless, we're not talking about the language, we're talking about code, and my points do not constrain themselves to c or c++ anyway.

2013-04-12 Reply Admin

faoileag:
What, you didn't show him the merits of writing a specialized method "isTrue(boolean)"?
And to be really on the save side, obviously isTrue's implementation must go all the way down: bool isTrue(bool aBool) { return isTrue(aBool); }

Not enough enterprisey:

bool isTrue(bool aBool) { return aBool ? isTrue(aBool) : isTrue(aBool); }

2013-04-17 Reply Admin

If you edit and recompile the JVM you can make the ternary operator occasionally throw a FileNotFoundException. The stack trace is guaranteed to raise some laughs :)

2013-04-24 Reply Admin

just me:
markfiend:
A former colleague was fond of if($boolean == TRUE) ...

Very useful pattern in C, in conjunction with:

#define TRUE 0 #define FALSE 1

I don't think you can do that, since those are already defined.

It should be #define FALSE (!TRUE) anyways.

Switching It Up at the End of the World

Leave a comment on “Switching It Up at the End of the World”