fix Issue 11301 - [2.064 beta] core.sys.linux.sys.mman triggers enum res...

[WalterBright]

...olution error

http://d.puremagic.com/issues/show_bug.cgi?id=11301

[MartinNowak]

Actually core.sys.posix.mman shouldn't import the linux header but I didn't want to copy the duplication for every architecture.

[WalterBright]

I view the whole thing as a more serious architectural issue due to the use of looping dependencies, usage of default enum values, and static conditionals. Heck, when working on this particular issue, it was fairly difficult to figure out just what MAP_ANON was supposed to be set to, let alone whether that was a correct value or not (based on what the system .h files say).

I've argued this at length before. Essentially, the enums should look like this:

version (linux) {
    enum MAP_ANON = ...;
} else version (OSX) {
    enum MAP_ANON = ...;
} else {
    static assert(0);
}

I.e. no default settings. It should be easy for the viewer to see and verify the correct value for his system. Yes, there will be duplication, a lot of duplication. This is NOT a problem. There are many more reasons - I should write up an article about this.

[WalterBright]

I didn't gripe about this for this fix, nor did I attempt to refactor this at this time, because this is just a patch to fix a regression.

[MartinNowak]

I've argued this at length before. Essentially, the enums should look like this:

The problem is that glibc has chosen this way of overlaying architecture specific declarations and generic declarations. Ignoring that fact and manually writing out 19+ architectures is too laborious and error prone.

[MartinNowak]

I.e. no default settings. It should be easy for the viewer to see and verify the correct value for his system.

Enhancement request Issue 11381.

[WalterBright]

Ignoring that fact and manually writing out 19+ architectures is too laborious and error prone.

The way I've done it is I write a C program that # include's the header in question, then run the gnu preprocessor on it, then I know unambiguously what the right values are.

Note that I have to run the preprocessor to figure out what values these things are actually being set to is one big reason why I eschew such complex imports.

As for error prone, I defy the casual observer to figure out what MAP_ANON is actually being set to on Linux with D.