Hacker News Reader

Comment by stormbrew | Hacker News Reader

If you ever want to give a c programmer a hard time, somehow sneak this into one of their headers:

    #define struct union

View on HN

    #define NULL rand()

better,

    #ifdef NULL
    #undef NULL
    #endif
    #define NULL (void*)((size_t)!rand())

* Doesn't trigger errors * Will almost always return 0 (every time rand() returns a non-0 value), so code will almost never crash.

This is so evil. Now hide this in some macro and the fun will never end.

Any preprocessor definition that changes the language like that example makes C programmers rage. As a rule, typedef and macros and friends should be avoided for clarity and debugging (opinion). An actual example of this: The programmer who created Bourne Shell, at Bell Labs in 1970s, intentionally did this to make C more like Algol. I think BSD still uses some of the original code. Understandably, not everyone liked the idea.

Legit usage: #define private public #include "some old thing I need the internals of but can't change.h"

C has no such keywords. Why the need for this hackery? Curious also if putting that in a header and including it in a C++ program even compiles without leading to undefined behaviour...

There's at least one compiler that adds visibility into the name mangling (is it gcc? Seems like the kind of thing they'd do), so if you unhide functions in this way you still won't necessarily be able to call them.

(The compiler is also free to change the object layout when you do this, too, though I've no idea whether any of them do.)

> Seems like the kind of thing they'd do

Forced to do by Microsoft C and C++ that mangle names.

What's the problem with typedef? It just names a new type rather than making things work differently than you'd expect.

The main misuse, again this is opinion based, is that it hides (obscures) the type of variable. If you have (say) a very large struct containing several member variables and functions, a programmer can be misled into returning it from a function or declaring it on the stack.

Of course there are reasonable uses for it. Contrary, to the above you might use it to intentionally make an object opaque as a way of abstracting its details from users or when declaring use of int/long in code.

Ah there are funnier, less obvious ways

The classic is:

  #define TRUE FALSE

or the even more pernicious:

  #define 1 0

Straight from the Ministry of Truth that one...

I once chased a bug which turned out to be: someone had #defined the letter 'T' as something else, in a chain of #include files nested 19 deep. Completely screwed up a bunch of C++ templates.

I mean, as the sibling notes, there's redefining true as false, but I think making all structs unions is much funnier, especially in that it's a uniquely C proposition. There are other languages that allow redefinition of true and false.

Also, I'm not sure how you think it's particularly obvious (as opposed to any other #define trick). It does only work if the project isn't warning-safe, as there are various ways this'll trigger ugly warnings (eg. using designated initializer syntax causes re-initialization warnings), but even then the warnings don't tend to actually tell you it's a union all of a sudden.

If you have others, I'd like to hear them.

  #define if while
  #define else while(!true){}

That should be interesting.

- Change the alignment of structs

- Remember the order of includes change how they are applied. Have a #define that changes something in a .h that's included in some files but not in others

- (Depending on the software) redefine rand() to be almost predictable or with a short loop

I read somewhere about someone redefining goto as goat, but I can't remember where.

Might have been the Lua Programming Gems book...

Reply on news.ycombinator.com