Why does the C preprocessor interpret the word “linux” as the constant “1”?

http://stackoverflow.com/q/19210935/1027148

by dcro • 13 years ago

275 57 13 years ago

alttag• 13 years ago

While I can't imagine much discussion here that couldn't occur on SO, I did want to say thank you for posting this. I found it quite interesting.

TeMPOraL• 13 years ago

+1, I love those interesting Stack Overflow (and Stack Exchange) posts that started to appear here every other week. I always learn something new/interesting from them. Thank you dcro :).

brey• 13 years ago

no doubt the SO question will soon be closed as "not a question" or "too interesting" or some other draconian response :(

blueblob• 13 years ago

This is awesome, I am going to divide by linux in my code everywhere in an attempt to obfuscate what I am doing.

berntb• 13 years ago

At least anyone trying to port your code to Windows will be a bit surprised... :-)

Edit: Or /.*BSD/. :-(

yk• 13 years ago

Non portability to Windows is a feature.

_kst_3• 13 years ago

You should divide by (linux - unix).

anttiok• 13 years ago

If you're in the habit of writing "struct sockaddr_in sin;", you'll probably be tempted to write "struct sockaddr_un sun;". Just don't expect that code to compile on Solaris.

robmcm1982• 13 years ago

Is that just hardcoded into the preprocessor itself? Or is part of ANSI C. Wondering if the MS C++ compiler will do this well.

simias6• 13 years ago

It's not and can be tuned using compiler options as mentioned in TFA. Definitely not standard.

army• 13 years ago

I spent at least an hour a while ago trying to track down a bug that turned out to be caused by exactly this. I couldn't work out what was happening until I looked at the preprocessor output.

twoodfin• 13 years ago

I'm increasingly turning to -E to debug these hard-to-understand problems. I'd love a -E2 or what-have-you that would be even more verbose, and list all preprocess transformations applied to a line and the source lines where they were defined.

Unfortunately, the standard preprocessor output doesn't provide a convenient way to do this without a comment format. I guess you could use a do-nothing #pragma.

Eventually, I'm sure somebody will spin up some extension to clang to show you the complete evolution of a block of code and what other code contributed to that evolution.

simias6• 13 years ago

Emacs has a "c-macro-expand" function which is quite hackish but extremely useful, IMO: it attempts to macro expand the region.

For instance running it on the following code in the middle of a C source file:

    #define BOGO_MAX(a, b) a > b ? a : b

    int test()
    {
      return BOGO_MAX(3 + 4, 5);
    }

Creates a new buffer containing:

    int test()
    {
      return 3 + 4 > 5 ? 3 + 4: 5;
    }

lclemente• 13 years ago

Just a note: This was on the stackoverflow weekly newsletter yesterday. If you're interested in more questions like this it's worth to check it out, I like it a lot.

Semaphor• 13 years ago

For anyone wondering where to subscribe: http://stackexchange.com/newsletters

PS: That's one of the few reddit customs I really like "link for the lazy" :)

simias6• 13 years ago

And that's why, in my opinion, non capitalized macros are always evil (yes, I'm looking at you linux kernel).

When I see a lowercase symbol used as a variable, I expect it's going to be some actual global variable. When I see a lower case symbol used like a function I expect it's an actual function. And then comes the day I want to take the address of the "function" and it fails. Or worse, I make a syntax error somewhere and because of the macro expansion it gives me the most perplexing error message in the world and it takes me 5 minutes and digging through 4 levels of include files to realize I forgot a colon or something.

Not to mention the mess if the macro is poorly implemented and does things like using a parameter several times which causes hard to catch undefined behaviours in the application. Nothing worse than having a seemingly harmless code like "foo(a++)" turn into the bug of doom because you didn't know foo was a macro. Please don't do that.

On the other end when I get a weird behaviour/error message around a capitalized symbol I automatically think that it must be a macro and go dig for the definition.

pcwalton4• 13 years ago

Yup. This is why in Rust macros have to end with a ! (and syntax highlighters know about this). This was a hard call, because it prevents using macros to create forms that look exactly like the built-in ones, but it prevents issues such as the one described in the OP.

ajross3• 13 years ago

But... the ability to use macros to create forms that look like "real" syntax is sort of the point. I don't think you can fix this with a language feature or style convention.

Metaprogramming is "dangerous" because the meta constructs don't (can't!) act like what they look liks. Metaprogramming is "great" because the meta constructs look like simple programming but have surprisingly deep behavior.

As I see it all you did was add a "!" to the confusion, honestly. People likely to get tripped up by e.g. the "address of macro" problem above are going to be no less confused by the extra syntax IMHO.

simias6• 13 years ago

Ah! That's great, I didn't know that. The more I hear about rust the more I like it. But then I'm reminded that it bakes garbage collection into the core language...

Oh well, perfection is no of this world.

rbehrends• 13 years ago

That's not the original issue. The problem is that the compiler silently predefines an undocumented macro. If the compiler silently predefined an undocumented variable, type, or function called "linux" or "unix", that too can be a problem. E.g., if there were a global function linux() on Linux systems only and you tried to define a global variable linux in your code, you'd get an error, too.

The clean solution is to do what clang does and generate informative error messages. In the case of macros, by showing the macro expansion history. For example, the following (using __STDC__ instead of linux for portability):

  foo.c:2:7: error: expected identifier or '('
    int __STDC__ = 1;
        ^
  <built-in>:159:18: note: expanded from here
  #define __STDC__ 1

Note that there can be other reasons to have macros that are syntactically different from functions and variables, but this isn't one of them.

WalterBright• 13 years ago

This is why a major focus of D was to figure out the valuable use cases of the C preprocessor, and instead design replacements for them that are semantically part of the language.

On the whole, this has been very successful - about half of D programmers have a C/C++ background and aren't shy about being vocal if there's something they really need.

lallysingh• 13 years ago

Two notes that'll date me pretty well:

(1) I had to port a game engine to solaris a few years ago. In that engine, if you looked up, you'd see a star emitting light. Guess what 3-letter, all-lowercase identifier was conflicting.

(2) Xt (only useful, really, if you're doing Motif work) had a macro or two that looked exactly like a function call, and had a very natural use case for incrementing an index you feed as an argument. If you knew not to do it, no problem. Otherwise, that was a mean bug to track down.

cpeterso2• 13 years ago

(1) I had to port a game engine to solaris a few years ago. In that engine, if you looked up, you'd see a star emitting light. Guess what 3-letter, all-lowercase identifier was conflicting.

sel? The suspense is killing me! :)

X-Istence• 13 years ago

The other problem is what I call greppability.

If I can't grep the header files/source code for a function call I will want to hurt you badly. Especially if a function call is hidden behind 6 - 7 different macro indirections!

/me glares over at OpenSSL...

icedchai• 13 years ago

Wow. This would've been amazing news... back in in 1992.

_kst_3• 13 years ago

Which makes it amazing news to people who weren't programming back in 1992.

BlackDeath3• 13 years ago

Some people here likely weren't even born in 1992.

blablabla123• 13 years ago

Linux is No. 1

marcosdumay• 13 years ago

Unless you compile it in Windows.

mmagin• 13 years ago

One could argue the real problem here is C's weak typing and lack of a proper boolean type.

stonewhite• 13 years ago

Doesn't name Keith Thompson ring a "bell"?

_kst_3• 13 years ago

Ding!

(No relation to Ken Thompson, if that's what you were thinking.)

CamperBob2• 13 years ago

More or less equivalent to the question, "Why is clang/llvm running roughshod over gcc?" It's the sum of a lot of really questionable decisions, like this one, made over a very long time.

sramsay• 13 years ago

Hacker News C-discussion response template:

"That's why [insert other language] has [insert feature]. This avoids some of the edge cases in [insert popular non-C language] along the lines of [insert unused obscure language]. Early benchmarks suggest it's almost as fast as C!"

Theriac25• 13 years ago

It's quite sad that you must specifically ask for conformance.

Why does the C preprocessor interpret the word “linux” as the constant “1”?

Related Stories