Live data from Hacker News

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

stackoverflow.com

51–60 of 60 posts

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

#51

Earlier quoted context omitted.

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…

> (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! :)

I think it's sol!

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

#52

Earlier quoted context omitted.

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…

> (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! :)

The star in question is 93 million miles away...

sun

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

#53
post #45

Earlier quoted context omitted.

People don't expect an ordinary-looking identifier like "linux" to macro-expand to something else, like the number 1. That was the source of the confusion in the OP. Syntactically distinguishing identifiers that will be macro-expanded from identifiers that won't does solve this problem.

But again, that's situational. This particular macro is confusing because it (1) looks like an identifier and (2) doesn't act like one, instead being a 1970's style platform identifier that (3) no one actually uses in favor of constructs like __linux__ or __GNU_SOURCE__ or whatever. But the more abstract point is that macros allow you to provide abstractions that do look just like an identifier (or function call, etc…

As I understand it, it is one of Rust's goals to be predictable in the code it runs/emits. This is fitting in a language designed for performance-critical systems. I see what you mean about the point of macros being that they can transparently add compile-time behavior. That's just a different, inconsistent philosophy from that of Rust.

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

#54
post #45

Earlier quoted context omitted.

But again, that's situational. This particular macro is confusing because it (1) looks like an identifier and (2) doesn't act like one, instead being a 1970's style platform identifier that (3) no one actually uses in favor of constructs like __linux__ or __GNU_SOURCE__ or whatever. But the more abstract point is that macros allow you to provide abstractions that do look just like an identifier (or function call, etc…

As I understand it, it is one of Rust's goals to be predictable in the code it runs/emits. This is fitting in a language designed for performance-critical systems. I see what you mean about the point of macros being that they can transparently add compile-time behavior. That's just a different, inconsistent philosophy from that of Rust.

Sure. Lots of successful languages exist without macro facilities. Lots exist with it. Frankly I don't see much correlation with "performance-critical systems" given that the overwhelmingly dominant languages in that field both have metaprogramming facilities (C++ has two!).

I was just quibbling with the idea that putting a magic "!" on a macro somehow makes it a better design choice. I don't think it does, either as a macro or as a safety mechanism.

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

#55
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!"

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

#56
post #13

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 somew…

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

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

#58
post #48
post #29

Earlier quoted context omitted.

Fair enough. I just have to cross my fingers and hope the GC won't catch on then! :)

We strive to avoid GC like the plague in the stdlib, and the language itself encourages users to do the same. I wouldn't go so far as to say that we try to make it hard to use GC in Rust, but we definitely believe that it's currently too easy to resort to it over better alternatives. This is why we're moving it into a library.

As a thought experiment, what would happen if the GC was removed altogether? What consequences would that have (good and bad)?

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

#59
post #48

Earlier quoted context omitted.

We strive to avoid GC like the plague in the stdlib, and the language itself encourages users to do the same. I wouldn't go so far as to say that we try to make it hard to use GC in Rust, but we definitely believe that it's currently too easy to resort to it over better alternatives. This is why we're moving it into a library.

As a thought experiment, what would happen if the GC was removed altogether? What consequences would that have (good and bad)?

No thought experiment necessary, you can do this today in two ways:

1) We have an attribute that you can stick in a module that will throw an error at compile time if a managed pointer gets used anywhere in that module, including in its dependencies. (Note: this is still experimental, and I'm not sure if it actually works yet.)

2) It's possible to write Rust entirely without a runtime, which means your result binary just plain won't contain any of the machinery for GC, tasks, or TLS (task-local storage).

This second approach does have consequences. Bad: random bits of the standard lib won't be usable, since our preferred means of error handling uses TLS (and some functional/persistent datastructures will use GC to handle cyclical pointers, since that's our only internally acceptable use case for GC). We have plans to look at dividing the stdlib into "usage profiles" to allow users to selectively disable certain runtime features while still remaining aware of exactly which pieces of the stdlib are still usable.

But the good consequences of disabling the runtime are that if your code exposes a C ABI, then you can write a library that can be called from any other language with a C FFI (i.e. basically every language, ever). This is actually one of my favorite things about Rust.

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

#60

Earlier quoted context omitted.

> (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! :)

The star in question is 93 million miles away... sun

oh, duh! The phrase "porting to solaris" should have clued me in.. <:)
Post reply on HN