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

[David Leimbach]

Well I guess we don't agree at all :-).  Have a nice day.

On Tue, Jun 8, 2010 at 11:49 AM, Paolo Bonzini <bonzini at gnu.org> wrote:

> On 06/08/2010 07:27 PM, David Leimbach wrote:
>
>> 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.
>>
>
> Ok, it is not C99.  It's POSIX.  Come on.  You're "drawing the line" in the
> most unreasonable place.  Anyway.
>
>
>     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.
>>
>
> No, it is _ctype.h with the underscore.  Nowhere in that file I read that
> it is internal use only.  Anyway, 4 seconds of grep and here is this from
> FreeBSD pthread.h:
>
> #define pthread_cleanup_push(cleanup_routine, cleanup_arg) \
> { \
>  struct _pthread_cleanup_info __cleanup_info__; \
>  __pthread_cleanup_push_imp(cleanup_routine, cleanup_arg, \
>     &__cleanup_info__); \
>  {
>
> #define pthread_cleanup_pop(execute)
>  } \
>  __pthread_cleanup_pop_imp(execute); \
> }
>
> Tada, __cleanup_info__.  BTW pthread_cleanup_{push,pop} just _cannot_ be
> implemented without macros of this kind, so pthreads cannot be implemented
> without either following your interpretation of the C99 standard, or
> breaking the user's namespace.
>
>
>  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.
>>
>
> I never said that.  I said that the choice of __block without trailing
> underscores was poor.  Nobody's perfect, GCC did the same for __thread, but
> guess what, there is a fixincludes for that:
>
> /*
>  * __thread is now a keyword.
>  */
> fix = {
>    hackname  = thread_keyword;
>    files     = "pthread.h";
>    files     = "bits/sigthread.h";
>    select    = "([* ])__thread([,)])";
>    c_fix     = format;
>    c_fix_arg = "%1__thr%2";
>
> };
>
> > As you say below, it's a young implementation, and possibly easier to
> > change that unistd.h.
>
> No, it's set in stone now.  I'm not suggesting changing it.  I'm just
> suggesting that for the first time clang is showing the need for
> fixincludes.
>
>
>  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?
>>
>
> I never proposed that.
>
>
>  Isn't that worse
>> than fixing glibc's header to comply with C99?
>>
>
> No need to say that again.  Repeating the same argument sounds like the
> preferred strategy of people writing to glibc bugzilla, just to see Drepper
> getting upset.  But we're not on glibc bugzilla, and I'm not Drepper.
>
>
>     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?
>>
>
> Nowadays fixincludes nowadays deals with all sort of problems.  It is even
> fixing old glibc to cope with removed extensions, or backwards-incompatible
> changes in the compiler (in addition to the above example with __thread, I
> can count two cases: C99 inline semantics, and removal of lvalue casts).  It
> can run arbitrary substitutions and sed scripts.  Here is another example:
>
> /*
>  *  Incorrect sprintf declaration in X11/Xmu.h
>  */
> fix = {
>    hackname = x11_sprintf;
>    files    = X11/Xmu.h;
>    files    = X11/Xmu/Xmu.h;
>    select   = "^extern char \\*\tsprintf\\(\\);$";
>
>    c_fix     = format;
>    c_fix_arg = "#ifndef __STDC__\n%0\n#endif /* !defined __STDC__ */";
>
>    test_text = "extern char *\tsprintf();";
> };
>
> Paolo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20100608/de4f01cb/attachment.html>