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

[David Leimbach]

On Tue, Jun 8, 2010 at 9:12 AM, Paolo Bonzini <bonzini at 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.
>>
>
> 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.
>
>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20100608/cf925eca/attachment.html>