[libdispatch-dev] linux + libdispatch + clang + blocks

[Paolo Bonzini]

> 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