This is awesome, I am going to divide by linux in my code everywhere in an attempt to obfuscate what I am doing.
You should divide by (linux - unix).
Why does the C preprocessor interpret the word “linux” as the constant “1”?
41–50 of 60 posts
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#42Doesn't name Keith Thompson ring a "bell"?
Ding!
(No relation to Ken Thompson, if that's what you were thinking.)
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#43And 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…
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.
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#44Earlier quoted context omitted.
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.
What's wrong with garbage collection being built into the language?
Nothing if you're writing your whole application in Rust. If you're making libraries or a kernel, though, it starts to present problems.
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#45Earlier quoted context omitted.
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…
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...) and do act like identifiers in the context where they're used. And that this is a good thing, because that kind of syntactic flexibility is useful in defining domain-specific languages that make the expression of hard problems clearer.
Adding a bunch of "!" to those DSLs isn't helping anything.
Basically, we have a macro that was abused here. Your solutions it to make it harder to abuse macros, mine is to accept the occasional abuse (with a "don't do that" in most cases, those here it's a backwards-compatibility problem) in exchange for more clarity on the hard stuff.
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#46More 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.
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#47Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#48Earlier quoted context omitted.
There's a project, zero.rs, that lets you have no runtime in rust. It's been shown that it's possible to make a simple kernel with it without too much pain. The disadvantage, of course, is that libraries will use garbage collection, and as soon as it's used, you get the runtime, so you can only use certain libraries designed for zero.rs, which causes fragmentation. All this would happen if gc was in the std library a…
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.
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#49And 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…
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.
Re: Why does the C preprocessor interpret the word “linux” as the constant “1”?
#50And 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…
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! :)