Define me baffled as to what possible reason has there ever been for a language to allow keywords and start/end delimiters and such to be redefined? WHY would it EVER be a good idea? I know, it makes for a ton of fun and plethora of WTFs but for any sane person... what?

It's the textual macro preprocessor, cpp, that does this. The C compiler first runs the source code through cpp -- which is blissfully unaware of any specifics of C syntax because all it does is look for lines beginning with # -- before attempting to compile anything. Think of it as yet another weird decision that probably looked sane, back in the black-and-white days when there was nothing better to hand.

A reason to allow this in general is that other languages can reuse the preprocessor. And code reuse is good right? Anyway the correct place to disallow this kind of code is not at the language level but style/human level.

TRWTF the code itself is total nonsense from a classical Win32 programming standpoint (and given the function names and the mention of DCs and handles I have to assume it's classical Win32 programming). Some of it uses entirely wrong function arguments so it wouldn't compile, and you can't delete a font that you have selected in a DC (the analogy would be freeing a linked list item while it's still linked in, though not as fatal because IIRC Windows will just do nothing). There are more issues, but.

Also I'm surprised they got the last "end;" to compile as I'm pretty sure all C compilers reject a semicolon at the end of a function definition... do they?

Of course all this is just a repeat of the good old original Bourne shell — its author Stephen Bourne was an Algol expert (having written an Algol 68 compiler at Cambridge) and decided to use macros to recreate as much of the Algol "feel" as possible in pre-standard (if not even pre-K&R!) C. And unlike this example, that one is real. Go take a look in various Unix code archives =P

A long long time ago, I had to program in C on a Bull mainframe using a terminal with no curly braces on the keyboard.
We had to create a file on a PC containing
#define BEGIN {
#define END }
and include it in every source file of the project.

@Uli Gerhardt: depending on how old the compiler in question is, trigraphs might not be present. And besides, I would probably argue that this is more obvious (but I don't have stats, so...)

@Tim Paterson (no,not really): #define if will compile (it is valid for a macro to expand to nothing); actually trying to use the new if keyword won't (the compiler won't see anything there and then complain about the { after the ) since that won't be valid). That define doesn't even make sense from the point of "making C look like Pascal" anyway, because Pascal uses if too...

I once worked with a guy that did something very similar to this. His obsession was with Oberon. When we told him that no, we were not going to port all of the code to Oberon, he set up a bunch of defines and came up with a bunch of rules to follow so that he could write code that compiled in both oberon and c++.

A lot of C will have fancy macros to emulate stuff like Java's try-with-resources or make complex locking schemes simpler and more reliable. These macros will often have some sort of START/END macro that hides opening and closing braces. I don't know if it's a good idea, but using the preprocessor to extend the syntax to support higher level constructs or hide direct use of hardware interfaces is entirely in spirit for C. That it permits something like this is largely irrelevant.

The last end (both ends, actually) compiles to a closing brace followed by an empty statement. That is certainly allowed inside a function, and AFAIAA (but I'd have to look it up, and I'm too lazy to do so) also outside it. Declaration statements are allowed anywhere in file scope, and so, I believe, are empty ones.

Why not use trigraphs or digraphs ? Not sure they were available then (it was pre ANSI C). And also, this was during my military service, I had very little experience coding in C (or in anything else) to be truthful.

Dr. λ the Creator of Variables, Binder of Variables, Applicator of Terms and β-Converter of Redexes(unregistered)2017-09-05ReplyAdmin

I worked someplace where there was an include file like that. Two Senior Architects had argued over whether to standardize on Turbo Pascal or C. The C guy won but the other one insisted on making C look like Turbo Pascal. He would spend hours each week "fixing" code so he could read it and everyone else spent hours turning it back into semi-readable C.

This may not be a WTF given it's age.
I once had to port a reasonably large 3rd party's Pascal system to C and came up with a scheme that tackled 95% of the code in one hit.
The solution was to use '#define' (to change things like 'end;' to '}') in a file called pascal.h to make the code compile with minimal change. It slashed the work from an estimated 6 months to 4 weeks actual.
It made a lovely maintenance nightmare for the rest of the team as even in Pascal, the code was garbage.
I wonder if this is the same code.

Darren: What did this get you that could not have been done using search and replace to turn "begin" and "end" into curly brackets, etc.? I'd think it would be easier for c programmers to work on bad c code than bad Pascal code.