Wrong-but-not-incorrect code

[Dave Vandervies]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?


dave

 

[Eric Sosman]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?

My personal favorite is this one-liner a colleague
found many years ago:

#define HASHSIZE 51 /* a small prime */

 

[Allan Bruce]

My personal favorite is this one-liner a colleague
found many years ago:

#define HASHSIZE 51 /* a small prime */

He obiously doesnt know his 3 time table above 3x10 ;-)
Allan

 

[Andrey Tarasevich]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?
...

signed char direction; /* either -1 or +1 */
unsigned offset; /* absolute distance */
T* ptr;

...
ptr += direction * offset;
/* Moving the pointer in direction specified by 'direction' */

In general case the code does not do what it was intended to do, since
the right hand side will be promoted and evaluated within the bounds of
'unsigned' type. However, on a 32 bit platform the code "worked" - the
pointer value wrapped around and ended up exactly where it would be if
code worked as intended. On a 64 bit platform (32-bit 'unsigned' and
64-bit pointers) the code started to fail for obvious reasons.

 

[Martin Ambuhl]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?

Your example itself could easily be made Worse. That sprintf call, for
example, is missing some casts, innit? And both that and the ReadImage
call could used a (void), innit?

 

[Chris Torek]

Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?

I have no idea how to rate the "wrongness" on a scale that
affords comparisons, but I once put a typo in my code so
that instead of:

if (expr && var)

I had:

if (expr &*& var)

The code still worked because the expression (whatever it was)
produced either 0 or 1 as its result -- it was perhaps something
like "a == b" -- and "var" was also logically boolean, holding
only either 0 or 1. Hence:

if (a == b &*& c)

was:

if ((a == b) & (*&c))

which was:

if ((a == b) & c)

which meant the same thing as the intended line.

 

[Kenneth Bull]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?

This isn't technically wrong but I thought I'd mention it. I knew this
chap who really loved GOTO statements, but upon entering a job he
realized the company's coding practices didn't allow them. So instead
he dropped a bunch of JUMPahead and JUMPbehind statemetns in his code
as a replacement. In a header file he hid the following:

jumpcommands.h
===============

#define JUMPahead goto
#define JUMPbehind goto

 

[CBFalconer]

.... snip ...

My personal favorite is this one-liner a colleague
found many years ago:

#define HASHSIZE 51 /* a small prime */

A few years ago, in this very newsgroup, 91 enjoyed similar fame.

 

[Charles Richmond]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?

My personal favorite is this one-liner a colleague
found many years ago:

#define HASHSIZE 51 /* a small prime */

"If 91 were prime, it would be a counterexample to your conjecture."
-- Bruce Wheeler

--
+----------------------------------------------------------------+
| Charles and Francis Richmond It is moral cowardice to leave |
| undone what one perceives right |
| richmond at plano dot net to do. -- Confucius |
+----------------------------------------------------------------+

 

[pete]

He obiously doesnt know his 3 time table above 3x10 ;-)
Allan

I add up the digits to see if a number is divisible by 3.
(5 + 1) % 3 == 0

 

[Dave Vandervies]

I have no idea how to rate the "wrongness" on a scale that
affords comparisons,

I was thinking along the lines of "invokes a `That can't POSSIBLY be
what it's supposed to say!' response, optionally accompanied by sever
aesthetic revulsion". Not well-defined or objective enough to make a
competition out of it, but comparing according to how well it matches
that is useful enough for war stories or language lawyering.

but I once put a typo in my code so
that instead of:

if (expr && var)

I had:

if (expr &*& var)

The code still worked because the expression (whatever it was)
produced either 0 or 1 as its result -- it was perhaps something
like "a == b" -- and "var" was also logically boolean, holding
only either 0 or 1.

Impressive. (But not nearly as impressive as if you'd had a plausible
reason for writing it that way intentionally.)


dave

 

[Chris Croughton]

A few years ago, in this very newsgroup, 91 enjoyed similar fame.

With a bit more reasonableness, since 13*7 is harder to recognise as
non-prime than 3*17...

Chris C

 

[Chris Dollin]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?

My personal favorite is this one-liner a colleague
found many years ago:

#define HASHSIZE 51 /* a small prime */

The writer clearly didn't play enough card games.

 

[Eric Sosman]

He obiously doesnt know his 3 time table above 3x10 ;-)
Allan

Or perhaps he was writing in decimal but thinking
in octal. "3x10 -- that's two dozen, right?"

(Exculpatory note: The colleague I mention was the
finder of the bug, not its author.)

 

[Ben Pfaff]

The writer clearly didn't play enough card games.

Are there many card games that call for a deck one card short?

 

[Rob Thorpe]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?


dave

There is some particularly contorted code in the message cracker
header windowsx.h in MS Windows that works. For instance:-

#define HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, fn) \
(LRESULT)(DWORD)(UINT)(BOOL)(fn)((hwnd), (HWND)(wParam), lParam)

Not that this is totally wrongheaded unlike the code you mentioned
above. It's just mildly derranged.

It's difficult looking at pieces of code like that you posted.
Sometimes pieces work, but are bad style, others work but are
undefined behaviour, still others are bugs but just happen to work.
When code is contorted it's very hard to tell which is which.

 

[Richard Tobin]

The writer clearly didn't play enough card games.

[/QUOTE]

Are there many card games that call for a deck one card short?

When you deal a pack of 52 cards between three players, you have one
left over.

-- Richard

 

[Chris Dollin]

Are there many card games that call for a deck one card short?

I don't know about "many", but there are several three-handed games
where all-but-one of the cards are dealt out, leaving the players
with 17 each. The left-over card may be left concealed, or it may
be exposed, or may be exchanged; it may determine the trump suit.

The two that immediately come to mind are Black Maria aka Hearts,
and Nullos. (Stares into space.) And Ninety-Nine.

 

[Tor Rustad]

Seen in a chunk of code I was looking at recently (not mine!):
--------
char* imgfilename[100];
sprintf((char*)imgfilename, "mask%d.dib", params.profile);
ReadImage((char*)imgfilename);
--------
(ReadImage is another part of the program's code that does exactly what
the reasonable reader would expect.)

For the CLC readers:
Can you, by artifical construction or actual experience, come up with
something that's more Wrong and yet still manages to be correct code
that performs the intended task?

Did a code audit once, of a program that had passed the integration
testing phase. It was a 3000 liner in a single source file. Well, that
happens... after scanning through +200 lines of globals.. I finally came
to the main.. puuuh!

The main() function was a +1500 liner, full of duplicate and
complicated rollback code....

Oh no... this wasn't any student code, the programmer had a CS
master degree and multiple years of C/C++ programming
experience. He had spent 3 months on this module. <g>

 

[Chris Croughton]

I don't know about "many", but there are several three-handed games
where all-but-one of the cards are dealt out, leaving the players
with 17 each. The left-over card may be left concealed, or it may
be exposed, or may be exchanged; it may determine the trump suit.

The two that immediately come to mind are Black Maria aka Hearts,

One of a number of games by both names, some are four-hand (the 'Hearts'
program distributed with Windows is one of the latter, but I first
played the same game four-handed some 30 years ago using the name "Black
Maria").

and Nullos. (Stares into space.) And Ninety-Nine.

There's also at least a couple where 16 cards are dealt to each player,
with 4 being left to exchange.

I've also played a three-hand version of Whist with the remaining card
being used to determine which suit was trumps. That was 30-odd years
ago as well (it was in a card games book which was at least 20 years
older than that)...

Chris C