• I'm not a robot (unregistered)

    #Define Frist

  • ImportanCommentDoNotDelete (unregistered)

    #define First 2nd #define Second 1st

  • El Dorko (unregistered)

    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?

  • Latengo Rica (unregistered)

    BYTE, back in the day, had an article about doing exactly this, as a teaching aid for people moving on from BASIC to C. There were a lot of Letters to the Editor in the next issue.

  • Your Name (unregistered) in reply to El Dorko

    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.

  • My Name (unregistered)

    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.

  • Your Name (unregistered) in reply to My Name

    I absolutely disagree. The correct way to disallow this is with hygienic macros, but I suppose at this point in time it's a bit late for this discussion.

  • Pietro Gagliardi (andlabs) (unregistered)

    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

  • mog (unregistered)

    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.

  • Anonymous coward (unregistered)

    I think there was a line in K&R, discussing the preprocessor, that said, "algol fans could" do exactly this. I did not realize it was a reference to Steve Bourne.

  • Uli Gerhardt (unregistered) in reply to mog

    You should have used trigraphs. :-)

  • Tim Paterson (no,not really) (unregistered)

    How exactly does "#define if" even compile? It's not defined to BE anything.

  • Pietro Gagliardi (andlabs) (unregistered) in reply to Tim Paterson (no,not really)

    @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...

  • Scobberlotcher (unregistered)

    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++.

  • shcode (unregistered) in reply to Tim Paterson (no,not really)

    that define is for "is", not "if" ;)

  • David (unregistered) in reply to El Dorko

    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.

  • Fred (unregistered)

    I think the guy was trying to port or replicate a feature from the Macintosh, which was built around Pascal.

  • RLB (unregistered) in reply to mog

    You do know about trigraphs (and now digraphs), don't you?

  • RLB (unregistered) in reply to shcode

    And the bonus WTF here is that with these definitions, if (whatEver is true) does not compile.

  • RLB (unregistered) in reply to Pietro Gagliardi (andlabs)

    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.

  • Somename (unregistered) in reply to mog

    Why not just use Digraphs that is exactly why they were in the language in the first place? "<%" = "{" "%>" = "}" See https://en.wikipedia.org/wiki/Digraphs_and_trigraphs

  • Quite (unregistered)

    Way back in the mists of history, an old schoolfriend of mine was reporting back on one of the first assignments he was given on getting a job after completing his computer science degree.

    "It's really cool," he said, "I'm writing a program to convert a Pascal program into a C program!"

    I never followed up on that, but I wonder whether he may have had some input into this ...

  • eythian (unregistered)

    This company was Microsoft, right? Anyone remember the MS-DOS 6.0 fdisk source code?

    https://ubuntuforums.org/archive/index.php/t-276438.html

    (With a little digging you can find the actual source yourself.)

  • (nodebb)

    TRWTF is deleting a GDI object that you just selected into a DC. The normal order of operations is:

    • Create the GDI object
    • Select it into the DC (saving the returned object)
    • Do your drawing
    • Select the returned object back into the DC
    • Delete the GDI object
  • mog (unregistered) in reply to Somename

    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)

    Haskell is a good programming language.

  • DBoone (unregistered)

    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.

  • Darren A (unregistered)

    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.

  • markm (unregistered)

    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.

  • V (unregistered)

    fake. there is no "is not" in pascal.

Leave a comment on “Classic WTF: #include "pascal.h"”

Log In or post as a guest

Replying to comment #486729:

« Return to Article