The Daily WTF: Curious Perversions in Information Technology

darin · 2006-11-15 Reply Admin

felix:
Quite useful sometimes, if you know about it. Only this guy found a C toolchain that isn't fully ANSI C. IMO, the WTF is bothering to support a non-standard implementation at all.

We have to do that. There's just too much time involved to convert everything to fully standard compilers. One is an older version of VisualStudio. The VisualStudio could be upgraded for everyone, but it's a hassle. The other compiler is trickier, since upgrading it means changing a lot of startup and run time library support code. We're going to GCC for newer projects, and there's a low priority task to port the older projects to it over time.

New projects have the luxury of starting things right. But I've been on projects where a decade old code base lived through several significant changes in the C++ language; and upgrading to a newer version of the compiler was a couple of months work. You can't really point them finger at them and claim that they were shortsighted by using a 1980's era compiler in the 80's.

darin · 2006-11-15 Reply Admin

Anonymous:
You know, the second one is why people work as a team, so you can ASK for advice, rather than leave behind confusing comments than end up on the Internet, bringing in amusement and laughter to our miserable lives.

Team members communicating with each other?? That's crazy talk!

darin · 2006-11-15 Reply Admin

Anonymous:

But supposedly it's standard behavior. Stupid and dumb syntax, but standard behavior.

This is very useful behavior when you use preprocessor macros. It allows construction of string literals from multiple parts at compile time, rather than building them at runtime using sprintf. It's also useful for breaking up long strings so they're more readable in the editor. The syntax could be better perhaps, but there are already enough operators in C.

2006-11-15 Reply Admin

Anonymous:
Colors have nothing to do with resolution. (I love the petty picking apart of others posts on this forum)

They do if you're limited to (for example) a single 16K memory page for all your video memory.

I'll use the Amstrad CPC, because it's what I learned to code on:

MODE 0: 160 × 200 × 4-bit colour <= 16K

MODE 1: 320 × 200 × 2-bit colour <= 16K

MODE 2: 640 × 200 × 1-bit colour <= 16K

I bet you're expecting that those four bits were neatly packed two pixels to a byte, aren't you? No such luxury.

I know that you personally might not have to pay much attention to it now that resolution is pretty much only limited by your monitor, but there is always an upper bound on (hres × vres × bpp).

2006-11-15 Reply Admin

JamesCurran:
Anonymous:

then 7.1.3: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces."
_filename_h_ is fine
er..um... what part of "are always reserved" did you miss?

I dunno, what part of "file scope" did you miss?

gwenhwyfaer · 2006-11-15 Reply Admin

Ash:
Yeah QBASIC did. F**k even my Sinclair ZX Spectrum did!

Which is truly remarkable, because nobody else's Spectrum did...

iwpg · 2006-11-15 Reply Admin

Anonymous:
#import is like gcc's #pragma once, except it's not deprecated. I believe there's an edge case where the same file is hard-linked to different paths and it could then be #imported twice, but that's somewhat unlikely.

From the GCC 3.4 release notes:

File handling in the preprocessor has been rewritten. GCC no longer gets confused by symlinks and hardlinks, and now has a correct implementation of #import and #pragma once. These two directives have therefore been un-deprecated.

2006-11-15 Reply Admin

Hell, even my Vic 20 had Else in it's basic...

Just WOW.

John Hensley · 2006-11-15 Reply Admin

Anonymous:
Hell, even my Vic 20 had Else in it's basic...
Just WOW.

not unless it was running a later version than the C64

2006-11-15 Reply Admin

Anonymous:
I'll use the Amstrad CPC, because it's what I learned to code on:
MODE 0: 160 × 200 × 4-bit colour <= 16K
I bet you're expecting that those four bits were neatly packed two pixels to a byte, aren't you? No such luxury

They were packed two pixels to a byte. Ok, the encoding was a little quirky, but I've seen worse.

2006-11-15 Reply Admin

Anonymous:
They were packed two pixels to a byte. Ok, the encoding was a little quirky, but I've seen worse.

Oh, wait. Yes, you're right. Sorry, it's been a while since Z80 assembler and my battered copy of SOFT968. I think in my head I was intending 'neatly' to mean the most and least significant four bits corresponding to the left and right pixels.

Of course, the truly inexplicable part was that, whatever mode one was in, the screen was addressed as if its actual resolution was 640 × 480.

Thanny · 2006-11-16 Reply Admin

Anonymous:
Anonymous:
Colors have nothing to do with resolution. (I love the petty picking apart of others posts on this forum)
They do if you're limited to (for example) a single 16K memory page for all your video memory.
I'll use the Amstrad CPC, because it's what I learned to code on:
MODE 0: 160 × 200 × 4-bit colour <= 16K
MODE 1: 320 × 200 × 2-bit colour <= 16K
MODE 2: 640 × 200 × 1-bit colour <= 16K
I bet you're expecting that those four bits were neatly packed two pixels to a byte, aren't you? No such luxury.
I know that you personally might not have to pay much attention to it now that resolution is pretty much only limited by your monitor, but there is always an upper bound on (hres × vres × bpp).

You don't have to go that far back to show the intimate relationship between resolution and color depth.

It wasn't all that long ago (oh, alright, 10+ years) that a graphics card with a 4MB frame buffer was $500. The more typical 1MB cards could handle 24-bit color at 640x480 only (and that only with packed pixels). If you wanted something crazy, like a massive 1024x768 screen, you were stuck with 256 colors. This was when 16MB of RAM cost about $600. I had a kickin' 486 back then, with $1200 worth of RAM and $500 worth of graphics, among other expensive parts that seem obscene today.

2006-11-16 Reply Admin

Anonymous:
JamesCurran:
Anonymous:

then 7.1.3: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces."
_filename_h_ is fine
er..um... what part of "are always reserved" did you miss?
I dunno, what part of "file scope" did you miss?

Can people start thinking at least 3 seconds before making stupid sarcastic replies? _filename_h_ is reserved at file scope. So you're allowed to use it as a local variable name but not as a macro name because then it would conflict with file scope names. Get it?

Xarium · 2006-11-16 Reply Admin

Anonymous:
Can people start thinking at least 3 seconds before making stupid sarcastic replies?

But ironic replies are ok, huh? :-)

identifier != macro

2006-11-16 Reply Admin

Anonymous:

The optimal solution would be just

// Can't use string concatenation because we need to support stupid XYZ compiler
printf("configuration: ");
printf( CONFIG_STRING );
printf( "\n");

There's no need to include multiple implementations when there's one that will work in all cases.

except (as has already been mentioned 500 times) that that will crash if CONFIG_STRING contains %s...
Replace printf with puts and you are ok...

sir_flexalot · 2006-11-16 Reply Admin

EvanED:
Dagon:
The first bit of code has a slight chance of being the result of somebody too addicted to editing videogames. Particularily, the game "Operation: Flashpoint" follows an almost identical syntax for its 'mini scripts' features.

Either that or it's just coding even more backwards than Visual Basic is to begin with (an achievement with all but the most recent of versions <<).
QBASIC had else blocks... I think... hmmm, now that I write that, I'm not sure. Anyone have better memory than I?

qbasic definitely had else blocks, I remember using them all the time. I actually thought that if then... goto was memory-inefficient anyhow. I've just entered an if block, and now i'm leaving in the middle of it to go run code somewhere else? Alsome!

2006-11-16 Reply Admin

Anonymous:
JamesCurran:
Anonymous:

then 7.1.3: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces."
_filename_h_ is fine
er..um... what part of "are always reserved" did you miss?
I dunno, what part of "file scope" did you miss?

There's also the fact that preprocessor macros are not the same thing as identifiers; the rule quoted above doesn't apply to macros at all. The person who originally posted that rule also posted the rule about reserved macro names, but that got clipped in the quoting; basically, reserved macros either begin with two leading underscores or a leading underscore and an uppercase letter. Macro names that begin with an underscore followed by a lowercase letter are not reserved.

captcha = stfu; damn straight.

2006-11-16 Reply Admin

Continuing the above chain...

Anonymous:
Can people start thinking at least 3 seconds before making stupid sarcastic replies? _filename_h_ is reserved at file scope. So you're allowed to use it as a local variable name but not as a macro name because then it would conflict with file scope names. Get it?

The concept of scope doesn't apply to preprocessor macros at all. Preprocessor macros are not identifiers, and the rules for identifiers don't apply to them.

_filename_h_ is not reserved. __filename_h or _Filename_h or _FILENAME_H_ would be, however.

2006-11-16 Reply Admin

Anonymous:

Continuing the above chain...
Anonymous:
Can people start thinking at least 3 seconds before making stupid sarcastic replies? _filename_h_ is reserved at file scope. So you're allowed to use it as a local variable name but not as a macro name because then it would conflict with file scope names. Get it?
The concept of scope doesn't apply to preprocessor macros at all. Preprocessor macros are not identifiers, and the rules for identifiers don't apply to them.
_filename_h_ is not reserved. __filename_h or _Filename_h or _FILENAME_H_ would be, however.

Need to correct myself. The concept of scope does indeed apply to macros, but not the same way as it applies to identifiers. Macros are scoped to the file in which they're defined, from the #define directive until either the end of the file or an explicit #undefine directive.

2006-11-16 Reply Admin

The junior college I went to used part time instructors...

which is the only reason I learned about the Else statement. The instructor informed us that the Fortran emulator or compiler we had didn't recognize Else, but this is how it would work if it did...

2006-11-16 Reply Admin

Anonymous:
Well, golly. Maybe they didn't use other compilers than GCC and XYZ. No, making it portable to every compiler imaginable is not a good use of your time.

#error a simple error directive wouldn't hurt, though

2006-11-17 Reply Admin

Anonymous:
Continuing the above chain...
Anonymous:
Can people start thinking at least 3 seconds before making stupid sarcastic replies? _filename_h_ is reserved at file scope. So you're allowed to use it as a local variable name but not as a macro name because then it would conflict with file scope names. Get it?
The concept of scope doesn't apply to preprocessor macros at all. Preprocessor macros are not identifiers, and the rules for identifiers don't apply to them.
_filename_h_ is not reserved. __filename_h or _Filename_h or _FILENAME_H_ would be, however.

It is effectively also reserved due to the following conflict:

#define _macro_
#include <file_that_uses_global_identifier_macro_.h>

// Ooop! Screwed up!

2006-11-20 Reply Admin

Anonymous:
Anonymous:

The optimal solution would be just

// Can't use string concatenation because we need to support stupid XYZ compiler
printf("configuration: ");
printf( CONFIG_STRING );
printf( "\n");

There's no need to include multiple implementations when there's one that will work in all cases.

except (as has already been mentioned 500 times) that that will crash if CONFIG_STRING contains %s...
Replace printf with puts and you are ok...

Or he could have just done it in one line: printf("configuration: %s\n", CONFIG_STRING);

2006-11-20 Reply Admin

Anonymous:
At least there was some code in the if blocks, at my previous employer (incidentally I 'escaped' after 3 months) the lead developer loved his no-ops.....

IF CONDITION THEN

****NOP

ELSE

<code here>

END IF

That could easily have been me. I do this all the time to avoid using negative logic in CONDITION. It's normally a

lot easier for readers of the code to understand positively-stated conditional expressions. Using the above form lets

me cleanly express the condition but take action only when it is negated.

2006-11-20 Reply Admin

Anonymous:
Yes, they could delete the GCC part of the clause, but that would increase the size of their binary in the GCC case because the three strings would be allocated separately in the image. And since this is likely an embeddes system, things like that matters.

There's room for implementations to differ, but at least for gcc 3.4.4 on i386, this is incorrect; the three strings are
concatenated at compile time; only one string results in the executable image.

2006-11-20 Reply Admin

Sorry; if I read the quoted part differently, my previous comment is irrelevant. It is true that if you delete the GCC part
of the clause, the binary size will increase. Not only would the three strings be allocated separately, but there would
be 3 function-invocation code sequences vice 1.

2006-11-28 Reply Admin

Anonymous:

Well chosen title but a part is missing:
We have met the enemy AND HE IS US :)
http://en.wikipedia.org/wiki/Pogo#.22We_have_met_the_enemy.....22

2006-12-04 Reply Admin

jtwine:

OneFactor:
You young whippersnappers - yer all soft! Back in the day of AppleBasic we had no else block. We'd number our lines and terminate our IF statements with a goto and we LIKED it. Our variables went uphill on both their letters and our strings had a dollar sign to remind us how expensive they were. ...

You mean "AppleSoft BASIC"? :P I remember doing stuff using both AppleSoft BASIC and Integer BASIC.

OneFactor:
There were games written in AppleBasic too, (not that we needed anything more than Lode Runner, Hard Hat Mack, and Rescue Raiders). Turn based strategy like Santa Paravia (how many games today let you go into debt and risk bankruptcy eh?) and full fledged RPG's that not only made you deal with encumbrance but also made charisma into a useful statistic. All that with no stinking else block.

Wow - HMM! I have not played that in years! Takes me back to really fun games like Repton and DROL :) Not to mention Lemonade (or Lemonade Stand?), which was written in Integer BASIC...! :) Thanks for the callback!

Peace!

And games like Lemonade in turn came from the minicomputer world of the 1970s. Many of the classics were found in the book 101 BASIC Computer Games, written by David H. Ahl and published in 1973 by Digital Equipment Corporation. Anyone remember Lunar Lander?

And getting back to the lack of an ELSE clause in early versions of BASIC: take a look at this page from a later (1978) version of Ahl's book, which describes differences between "normal" BASIC and the then-new Microsoft 8080 BASIC running on an Altair 8800.

Note that "normal" (i.e. Dartmouth) BASIC only supported one form of the IF ... THEN statement:

IF condition THEN linenumber

Microsoft added the alternative form

IF condition THEN executable statement(s)

However, neither version provided an ELSE clause.

2006-12-04 Reply Admin

Anonymous:
Like AppleBasic, I used a version of BASIC back in 1980 that allowed only "IF <condition> THEN GOTO <line number>". Variable names could be only a single-letter ("A") or single-letter$ (A$). If you had more than 26 variables you had to use arrays, hehe. The best part was the interface: old teletype connected to mainframe at 300 baud.
Captcha=giggity...kinda like the sound of a teletype.

300 baud? You were so spoiled. Ours ran at 110 baud (that's 10 characters per second). And we dialed in using a rotary dial telephone, and a modem with an acoustic coupler (directly connecting non-Bell equipment to Ma Bell's precious phone lines being verboten in the 1970s.

We had an entire school district running off a single timesharing system, a PDP-8 minicomputer. Main memory (core, as in magnetic core, not semiconductor RAM) was 6 banks, each 4K words of 12 bits each (the operating system ran in two banks, and the users took turns getting swapped into the other four). Our "mass storage" device was a single-platter 14-inch disk drive with fixed heads (which at least made for fast access since seek time was zero). It's hard to believe now, but that system could handle up to sixteen simultaneous users.

I learned to program on that system - Basic and assembler. Fond memories, especially of the sound of those teletypes kachugging away, and the smell of warm machine oil. And saving my programs by punching them onto paper tape (again at 10cps). Still have a box of them tucked away somewhere.

RevMike · 2006-12-27 Reply Admin

Anonymous:
Anonymous:
(condition) && foo();
foo() || die;

This syntax actually works in a lot of languages, including C: it is perfectly legal to just have an expression as a statement, and conditional operators will only evaluate the right hand term if the left hand term is not enough to figure the result of the expression.
I don't remember stumbling on it ever in any of the C or C++ code I worked with, though. Given the amount of people who enjoy nothing more like packing as much stuff into a single line of code, you'd expect this to be more common.

My copy of K&R is at home so I can't look this up. I do remember specifically setting compiler options controlling short circuit evaluaton on a Microsoft C product circa 1990.

My guess is that the spec was ambiguous on short circuit evaluation, that it was left to be implementation dependent, or that many common implementations diverged from the spec. Regardless, no decent programmer would needlessly rely on functionality that was of limited benefit and is implementation specific. Old habits die hard, so it is not common to see the idiom today.

2007-09-29 Reply Admin

(Wow, you have a lot of spam piling up there.)

The first part of this "We Have Met the Enemy" (with the lousy VB code) is from me. The company is "Main Sequence Technologies" based in Willoughby, OH.

The post was referring to their flagship product "PC Recruiter" which is a buggy half-assed program (even according to some of their own developers) that deals with managing the hiring process.

One of the company's four owners, Bill Kubichek (head of sales) has even been known to go around bragging about being a spammer. Bill also spends most of his time in Hawaii doing god knows what.

If you haven't noticed, I've gotten tired of protecting this worthless company's identity. I've got another job lined up so I'm not worried about getting canned at this one.

2017-07-03 Reply Admin

this article reminded me of a story i read somewhere, probably on this site: a programmer never heard of the "end " command, or was it the "return" command, and instead used an intentional "divide by zero" error!

We Have Met the Enemy

Leave a comment on “We Have Met the Enemy”