On Tue, Jun 8, 2010 at 9:12 AM, Paolo Bonzini
<bonzini@gnu.org> wrote:
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.
This is not a strawman because it is not an argument. I'm telling you that by definition, C99 says double underscore names are for the implementation. It's also not arguable that unistd.h is not part of C99's standard library by definition, and therefore had no business using double underscored names to begin with.
If we were talking about stdlib.h, it would actually be a different story. I'm not the one who drew these seemingly arbitrary lines, but they exist all the same.
It may very well be that the folks sitting on the committee sometimes are out of touch with reality, and don't realize that C99 compilers don't always ship with exactly their own libc, and that libc libraries often are scoped to handle far more than just the C99 defined standard library, but the point of the standard is try to keep things portable, and to lay down some rules for users and implementors to collaborate and work together.
Someone's not following the rules, and it's not the clang or llvm teams.
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...
Unfortunately for your counter-example, ctype.h is part of C99, and therefore a use of double underscored names is valid within that context as far as I can tell.
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?
It's irrelvant what's more common if you're looking at this from the perspective of someone trying to comply with C99.
If you're looking at this situation from the perspective of what changes will affect the most users, then glibc still loses most likely because I bet the number of people with Clang -fblock enabled code outnumbers the people maintaining glibc and using the __block definition (which is illegal by C99) from unistd.h.
I didn't draw the lines, so if they don't make sense, do not blame me, but they're there to help people collaborate and write portable code. Claiming that Apple and the LLVM team is being a poor collaborator for using __block is hard to maintain when that entire namespace was allotted to them by the C99 standards committee.
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.
I disagree with your claim that "everything is against clang", but you make a valid point all the same.
GCC is a de-facto standard due to its ubiquity and longevity, and there's some value in tracking this, as Intel has realized with their compiler toolchain. And you're correct that Clang could have done this for __block, but the primary target platform was *not* glibc for this stuff.
Maybe it could easily be __block__ going forward, but don't you think that's going to change a lot of people's libdispatch related code just to make things compatible with unistd.h from glibc? Isn't that worse than fixing glibc's header to comply with C99?
As you say below, it's a young implementation, and possibly easier to change that unistd.h. All I know about the lack of desire to make the change in unistd.h for glibc is that Ulrich Drepper doesn't want to do it, and believes incorrectly that the Clang and LLVM develoeprs "stole" something that he thought was his, when it really wasn't.
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.
fixincludes was to deal with non-ANSI headers right? How is that going to help with the __block keyword? I can't find the Block implementation text that used to be at
clang.llvm.org anymore as the site has moved stuff around or deleted the file, but my impression is it's a keyword, not a macro.
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.
From one perspective you're correct, however unistd.h is a user of the standard C library code, and should not have used double underscore identifiers per the C99 standard. They're ALL reserved.
Dave
Paolo