Bug 1009623 - unistd.h uses a reserved word (__block) from clang++ -fblocks [All Fedora]
unistd.h uses a reserved word (__block) from clang++ -fblocks [All Fedora]
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Carlos O'Donell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-18 13:50 EDT by Derek Atkins
Modified: 2016-02-04 01:40 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-04 01:40:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Derek Atkins 2013-09-18 13:50:43 EDT
Description of problem:

clang(++) reserves the word __block when you enable -fblocks support.  Alas, unistd.h has (for a VERY long time) used this as the name of a variable, which causes clang to throw a fit:

/usr/include/unistd.h:1147:35: error: __block attribute not allowed, only
      allowed on local variables
extern void encrypt (char *__block, int __edflag) __THROW __nonnull ((1));


Version-Release number of selected component (if applicable):

I have verified this issue in versions of glibc-headers from 2.12-1.107.el6_4.4 all the way to 2.16-34.  It's an issue in all recent versions of Fedora and RHEL.


How reproducible:

This is 100% reproducible.


Steps to Reproduce:
1. cat > /tmp/test.cpp <<EOF
#include <unistd.h>
EOF
2. clang++ -fblocks -c /tmp/test.cpp -o /tmp/test.o
3.

Actual results:

$ cat /tmp/test.cpp 
#include <unistd.h>
$ clang++ -fblocks -c /tmp/test.cpp -o /tmp/test.o
In file included from /tmp/test.cpp:1:
/usr/include/unistd.h:1147:35: error: __block attribute not allowed, only
      allowed on local variables
extern void encrypt (char *__block, int __edflag) __THROW __nonnull ((1));
                                  ^
1 error generated.
$ clang++ --version
clang version 3.3 (tags/RELEASE_33/rc2)
Target: x86_64-redhat-linux-gnu
Thread model: posix

Expected results:

clang++ -fblocks should work fine with all system headers.


Additional info:

You can fix the file by:

  sed -i -e 's/\*__block/\*__libc_block/g' /usr/include/unistd.h

When you do this the compiler works just fine.  If you want the one-line diff I can supply that to you.
Comment 1 Carlos O'Donell 2013-09-19 10:20:42 EDT
Derek,

This needs to go upstream immediately. It's a similar issue to what upstream has with __unused and BSD. Once upstream accepts it we can backport it.

I fought to allow this kind of change in glibc, and I would champion this kind of patch for you (I'll do the review and check it in).

Could you post your patch upstream on libc-alpha@sourceware.org following the contribution checklist? Please CC me.

https://sourceware.org/glibc/wiki/Contribution%20checklist

Cheers,
Carlos.
Comment 2 Carlos O'Donell 2013-09-19 10:21:37 EDT
Note: The word __block can't be reserved, it's in the implementation namespace. However the implementations need to coordinate.
Comment 3 Carlos O'Donell 2013-09-24 02:03:26 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=5974585

commit a9c7f8acc7f553304a6d73fbee69b807f1c56fa6
Author: Carlos O'Donell <carlos@redhat.com>
Date:   Tue Sep 24 02:01:06 2013 -0400

    Resolves: #1009623
    
    - Avoid the use of __block which is a reserved keyword for clang++
Comment 4 Derek Atkins 2013-09-24 09:32:15 EDT
(In reply to Carlos O'Donell from comment #3)

Sorry, I was travelling.  Does this update mean I don't need to send a patch to the upstream provider?
Comment 5 Carlos O'Donell 2013-09-24 12:31:33 EDT
(In reply to Derek Atkins from comment #4)
> (In reply to Carlos O'Donell from comment #3)
> 
> Sorry, I was travelling.  Does this update mean I don't need to send a patch
> to the upstream provider?

Sorry, yes, that's right. The glibc team will ensure that our rawhide patch goes upstream. It isn't fixed in f18, but it is fixed in rawhide and all fX releases going forward.
Comment 6 Derek Atkins 2013-09-24 12:37:32 EDT
(In reply to Carlos O'Donell from comment #5)
>
> Sorry, yes, that's right. The glibc team will ensure that our rawhide patch
> goes upstream. It isn't fixed in f18, but it is fixed in rawhide and all fX
> releases going forward.

Awesome!  Any chance this fix can get pushed into EL6, too?
Thanks!!!
Comment 7 Carlos O'Donell 2013-09-24 16:02:06 EDT
(In reply to Derek Atkins from comment #6)
> (In reply to Carlos O'Donell from comment #5)
> >
> > Sorry, yes, that's right. The glibc team will ensure that our rawhide patch
> > goes upstream. It isn't fixed in f18, but it is fixed in rawhide and all fX
> > releases going forward.
> 
> Awesome!  Any chance this fix can get pushed into EL6, too?
> Thanks!!!

No, sorry, at present we won't be pushing this fix into EL6.
Comment 8 Jaroslav Reznik 2015-03-03 12:10:00 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 9 Florian Weimer 2016-02-04 01:40:25 EST
This was fixed upstream in glibc 2.19, and is present in all supported Fedora releases.

Note You need to log in before you can comment on or make changes to this bug.