bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #34602] compiling NSRegularExpression.m using clang, it emits a war


From: Richard Frith-Macdonald
Subject: [bug #34602] compiling NSRegularExpression.m using clang, it emits a warning that it doesn't support blocks
Date: Thu, 20 Oct 2011 09:02:56 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22

Follow-up Comment #2, bug #34602 (project gnustep):

This looks like a clang bug.
As far as I can tell ... the state of affairs is as follows.

1. glibc in one of it's headers used __block as an identifier.  They chose
that because by convention the underscore prefix is reserved for the system
(stuff like libc, other core system headers, the compiler etc) and it wasn't
in use by any other software, but while legitimate, they could have made
better choices.

2. then Apple chose __block as a type qualifier for their addition of blocks
to the programming language ... I guess they didn't check to see if it was
already in use (or only checked about OSX).  I hate the use of underscores
here as it's totally inconsistent with other type qualifiers in C/ObjC, but
we're probably stuck with it.

3. we try to work around the conflict by redefining the __block in the
preprocessor before including the system headers and undefining that again
afterwards.  But then find that clang has defined __block, so we have to
undefine it, redefine it, and then undefine it again.

Thus far I'm sure of the facts ... the next is inference:

4. Now it looks like clang doesn't support __block as a proper
qualifier/reserved word, so our workaround has trashed clang's preprocessor
definition, and clang then doesn't know how to deal with __block when it
appears in the code used as a type qualifier.

I'd guess we could do some sort of test to see what clang defines __block to
be, and redefine it to that in gnustep-base after having included the system
headers ... but that sounds like a very fragile hack ... probably it would be
betterto see if the clang developers can fix things somehow.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34602>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]