It seems pretty cut and dry to me.
1. C99 defines that double underscored tokens are reserved identifiers in the implementation of C99. 2. C99 is defined by both the compiler and the standard C libraries defined in C99. 3. unistd.h is not part of C99.
You know perfectly that the same thing could have happened with __block was used in stdlib.h (libdispatch is using _GNU_SOURCE, so it is allowing explicitly to declare non-C99 things in stdlib.h). So this is at best a strawman. BTW, from your favorite libc's _ctype.h: static __inline int __istype(__ct_rune_t c, unsigned long _f) { return (!!__maskrune(_c, _f)); } __istype looks like a nice candidate for a new compiler keyword...
Unistd.h is therefore clashing with a C99's totally valid usage of a double underscored and reserved name. Yes, unistd.h is shipping with a libc implementation, but nowhere does it say in C99 that that's an excuse for utilizing the C99 implementation's reserved namespace.
The alternative is not using double underscores and breaking on anyone using "#define block blah". What kind of conflict do you think is more common? User macros or extended keywords?
One could question whether it is a good idea or not to tell the users of your C99 implementation to have to use extensions to the language via the use of double underscored names, but it really does say in C99 that these are there for ANY use by the implementation.
True, but everything IMO is against clang in this circumstance: 1) GCC has followed the standard of using __keyword__, instead leaving __keyword to libc and libstdc++. __complex__, __asm__, __attribute__, you name it. No reason why clang should not have done the same for __block. It wouldn't have clashed with glibc. 2) past experience has suggested a workaround, namely "fixincludes". Currently clang is being sloppy in this respect; it can afford that because it only supports a few targets (basically Linux and Mac OS X). It's a young project, so I don't have anything against that. But sooner or later you will have to deal with the consequences of not controlling the whole C99/POSIX environment.
This means that if you see double underscore'd identifiers in a user's code, that this code is at worst "not portable to other compiler environments".
libc is not user code. Paolo