The Daily WTF: Curious Perversions in Information Technology

2009-03-23 Reply Admin

tengfred:
Anon:
trincanapera:
I used to work with a girl like that.

Pictures or it didn't happen! There are no girls in IT. ;)

http://xkcd.com/322/

The instant I read Anon's post I cringed. That xkcd immediately sprang to mind as well. Thank you sir.

2009-03-23 Reply Admin

Hey now, there are too girls in IT! Don't go getting all sexist on us now.

Mr B · 2009-03-24 Reply Admin

Jade:
Hey now, there are too girls in IT! Don't go getting all sexist on us now.

Just two eh? Who's the other one?

2009-03-24 Reply Admin

Greg:
Ah, I forgot the "all compilers follow the (C) standard, and never have any bugs" camp. Please, please tell me you're not building medical devices or missiles that will make some error about !foe.
Maybe you've just been lucky, or are still in school, but there are some fairly stupid bugs in compilers sometimes. Use the #define's, or make ones yourself that are bulletproof.

Please tell me you're not building medical devices or missiles, using a compiler with a stupid bug about how it evaluates !0.

2009-03-24 Reply Admin

TheRealFoo:
I have yet to see a XML parser that is clean, fully standard-compliant and does not require you to overturn your data structures or code logic.
(Links welcome.)

I've replaced a couple of in-house XML parsers with the Expat parser. As it's a SAX parser written in C which uses function pointers for callbacks, it has no effect whatsoever on data structures. If your in-house parser's logic wasn't push event driven, then it will have some effect on that.

2009-03-30 Reply Admin

too_many_usernames:
I do write for embedded systems (safety-critical ones even) and I'm still amused that people think this is needed because a floating-point compare is inaccurate.
Fundamentally it's not; the issue isn't with the comparison itself. The reason you do this isn't because the compare is broken, but because you know there is enough error in the numbers being compared that you want a deadband around them for purposes of comparison.

Agreed 100%. Actually, it's one of my pet peeves that people act like it's always wrong to compare floating point numbers directly, as if the comparison itself is nondeterministic or as if all the floating point numbers in a running program are continuously undergoing random little changes.

I've even heard it said that "When dealing with floats, >= and <= are acceptable, but never use ==, !=, <, or >", and that guideline is complete nonsense (not to mention internally inconsistent). Even for checking exact equality of floats, there are some cases where you really do need to do that, cases where doing anything else would be incorrect.

If it's "always wrong" then why don't compilers show warnings about it (if not disallow it)? It necessarily must be determined on a case-by-case basis. Sure, it takes experience to be able to do so correctly, but a blanket rule is counterproductive here.

2009-03-31 Reply Admin

Capt. Obvious:
That said, in all my projects, !0 = 1, and 1 = false;

Eww.

2009-03-31 Reply Admin

Anonymous:
I've even heard it said that "When dealing with floats, >= and <= are acceptable, but never use ==, !=, <, or >", and that guideline is complete nonsense (not to mention internally inconsistent).

Seriously dude! That's patently false to anyone with a speck of common sense. If >= works then, barring incompetence, so do the rest. We can only pray that whomever you heard that from has learned his lesson and stopped preaching heresies about data types he does not understand.

And floats/doubles are dangerous types to misunderstand.

2009-04-06 Reply Admin

are you certain you can't do it in C? (or at lest simpler than what you wrote)

math.h host's a plethora of functions, (what puzzels me is some of the really simple things that got left out...)

it's late and I'm very tierd so I have no clue what the point of the comparison is but here is a host of compares without exceptions, I'm pretty sure at least one of them could simplify what you wrote, and make it portable to non-intel machines since it's standard c99:

isgreater() determines (x) > (y) without an exception if x or y is NaN.

   isgreaterequal()
          determines (x) >= (y) without an exception if x or y is NaN.

   isless()
          determines (x) < (y) without an exception if x or y is NaN.

   islessequal()
          determines (x) <= (y) without an exception if x or y is NaN.

   islessgreater()
          determines (x) < (y) || (x) > (y) without an exception if x or y is NaN.  This macro is not equivalent to x != y because that expression is true if x or y is NaN.

   isunordered()
          determines  whether its arguments are unordered, that is, whether at least one of the arguments is a NaN.

also since several of those probably are macros that expand to built in functions (or built int functions themselves) that use FUCOMI the compiler might just constant fold multiple invocations, and would be able to optimize around it better which inline asm will interfere with, so if at all possible avoid inline asm unless you're REALLY gonna optimize it, because otherwise the compiler WILL do a better job.

2009-04-06 Reply Admin

WRONG !0 generally results in 1

MAX_INT for an unsigned would be ~0 or ((unsigned)-1)

2010-12-25 Reply Admin

I could imagine that it was discovered that those floats could take NaN and INF values, and that this code submit fixes the compare function to support those.

NaN and INF aren't part of ISO C and can't be checked there. So you'd need inline assembly.

Of course the real fix would be to ensure that the flaots could never take those values, but that could require larger code changes...

But since there are no source code comments mentioned in the article, and no versioning submit text, it's just a guess.

2010-12-25 Reply Admin

Ah, sorry, comments like what I just wrote appeared on the last comment page :)

2011-04-04 Reply Admin

pb:
The real WTF is the writer of this story. He thinks the two pieces of code are interchangeable (because the target of this missive has a history of rewriting code).
Hello!! the function name and signatures are different so there is no way these two pieces of code are for the same use.

I was confused by this as well, but eventually concluded that the 'author' was giving two different examples of how the 'superstar' was coding, not a 'before and after' example. If this is the case, the author is still guilty of some terrible writing, but didn't make quite so large an error as it might seem.

But I could be wrong.

CAPTCHA - saluto: those who are about to flame (me), I salute you.

2013-03-04 Reply Admin

Anonymous:
Actually, it's one of my pet peeves that people act like it's always wrong to compare floating point numbers directly, as if the comparison itself is nondeterministic or as if all the floating point numbers in a running program are continuously undergoing random little changes.

Hey look everybody, this guy computes with doubles in his head and always knows what the rounding error will be. This must be why he's the Capital-A Anonymous and I'm just plain ol' anonymous.

Meanwhile, on planet earth, most of us are quite happy to call the little changes random.

Code Ownership Gone Awry

Leave a comment on “Code Ownership Gone Awry”