[libdispatch-dev] linux + libdispatch + clang + blocks
bonzini at gnu.org
Tue Jun 8 09:12:30 PDT 2010
> 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.
More information about the libdispatch-dev