[Bug libc/11157] __block is a reserved word with clang -fblocks

[Bug libc/11157] __block is a reserved word with clang -fblocks

[mark at heily dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11157

Mark Heily <mark at heily dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at heily dot com

--- Comment #6 from Mark Heily <mark at heily dot com> 2011-12-27 02:41:15 UTC ---
A better workaround is to override /usr/include/unistd.h with your own private
copy. See below for an example that you could include into your project source
tree as 'unistd.h'. 

/*
Credit: 

   David Chisnall
   http://comments.gmane.org/gmane.comp.desktop.etoile.devel/1556

*/

#ifdef __block
#       undef __block
#       include_next "unistd.h"
#       define __block __attribute__((__blocks__(byref)))
#else
#       include_next "unistd.h"
#endif

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[ppluzhnikov at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11157

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |ppluzhnikov at google dot
                   |                            |com
            Version|2.11                        |unspecified
         Resolution|INVALID                     |

--- Comment #7 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-06-13 18:51:11 UTC ---
I would like to revisit this issue:

- it is trivial to change glibc public headers to not use __block
  (there are only 5 instances).

- eglibc has a patch to rename __block to __libc_block:

  r10807 | joseph | 2010-06-24 07:52:06 -0700 (Thu, 24 Jun 2010) | 5 lines

  2010-06-24  Mark Heily  <mark@heily.com>

        * crypt/crypt.h, posix/unistd.h: Use __libc_block instead of
        __block.

It is certainly possible to work around this on the Clang side, but it is also
certainly more work, and more opportunity for things to go wrong.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[lubos at dolezel dot info]

http://sourceware.org/bugzilla/show_bug.cgi?id=11157

Lubos Dolezel <lubos at dolezel dot info> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lubos at dolezel dot info

--- Comment #8 from Lubos Dolezel <lubos at dolezel dot info> 2012-08-08 08:21:38 UTC ---
Then why don't you start naming arguments "__thread", "__real__" or something
even more stupid to create more collisions? I see no harm in renaming an
argument, especially in the declaration.

Changing the argument name would be no serious effort on your part and would
make life easier for others.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[bonzini at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11157

Paolo Bonzini <bonzini at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #9 from Paolo Bonzini <bonzini at gnu dot org> 2012-08-08 08:50:39 UTC ---
Lubos, please read the comments.

GCC has a "fixincludes" utilities that adapts problematic headers.  If glibc
started "naming arguments __thread, __real__ or something even more stupid to
create more collisions", GCC's fixincludes would fix those and you would not
notice.

If clang doesn't have a fixincludes utility, that's its problem.  Please open a
bug at clang.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11157

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com
         Resolution|WONTFIX                     |FIXED

--- Comment #10 from Carlos O'Donell <carlos at redhat dot com> ---
Fixed.

commit 84ae135d3282dc362bed0a5c9a575319ef336884
Author: Meador Inge <meadori@codesourcery.com>
Date:   Thu Nov 21 16:57:37 2013 -0500

    Use __glibc_block in public headers.

    As detailed in PR11157, the use of '__block' is known to interfere
    with keywords in some environments, such as the Clang -fblocks extension.
    Recently a similar issue was raised concerning the use of '__unused'
    and a '__glibc' prefix was proposed to create a glibc implementation
    namespace for these sorts of issues [1].  This patches takes that
    approach.

    [1] https://sourceware.org/ml/libc-alpha/2012-02/msg00047.html
    [2] http://lists.debian.org/debian-glibc/2013/11/msg00020.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11157

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[bonzini at gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=11157

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[bonzini at gnu dot org]

------- Additional Comments From bonzini at gnu dot org  2010-06-08 07:39 -------
> By convention, double underscores are reserved for the compiler, single
underscores for the libc.

This is wrong and makes no sense.  By _the standard_ double underscores are
reserved for the implementation (and the namespace is shared by the compiler and
libc; they have to live together).  There are no conventions about how to share
the namespace.

> Using them as parameter names in the header is entirely wrong and is not
guaranteed to work on any standards-compliant compiler.

This is also imprecise.  It is not guaranteed to work, period.  Your
interpretation of the standard is that libc should not use argument names in its
header file prototypes.  I kind of agree that it is safer and it would fix _this
particular case_ but in general it is not possible.  It would mean no inlines
and in C++ not even templates, unless you want to "uglify" foo as __libc_foo
which is not reasonable.

GCC has a "fixincludes" utilities that adapts problematic headers.  Most of the
time it fixes code that is indeed wrong according to the standard, but a few
adjustments are for conflicts with its own usage of __ identifiers.  If clang
doesn't have a fixincludes utility, that's its problem.

BTW the workaround is simply to do

   #define __block __glibc_block
   #include <unistd.h>
   #undef __block

which is all but unreasonable.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=11157

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[Tanktalus at gmail dot com]

------- Additional Comments From Tanktalus at gmail dot com  2010-04-06 23:31 -------
http://web.archive.org/web/20040209031039/http://oakroadsystems.com/tech/c-predef.htm#ReservedIdentifiers
seems to disagree with you.  The C standard also disagrees with you: anything
starting with an underscore is reserved to the compiler.  The compiler is free
to create new anything that starts with an underscore.

Just googling for "reserved identifiers c" also shows
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/language/ref/clrc02reserved_identifiers.htm
- IBM's compiler also says "Identifiers that begin with an underscore are
reserved as identifiers with file scope in both the ordinary and tag name
spaces."  Since "__block" starts with an underscore, it's reserved for the compiler.

Googling for "reserved identifiers c gnu" shows
http://www.gnu.org/s/libc/manual/html_node/Reserved-Names.html, for the gnu C
compiler, which says "all identifiers regardless of use that begin with either
two underscores or an underscore followed by a capital letter are reserved
names. This is so that the library and header files can define functions,
variables, and macros for internal purposes without risk of conflict with names
in user programs."  In other words, your use of __block is a conflict and should
be changed, just to fit with GNU C.

Basically, these are reserved specifically so that the compilers can define new
identifiers without stealing by reserving in advance everything that starts with
an underscore.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=11157

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-04-04 18:32 -------
(In reply to comment #2)
> By convention, double underscores are reserved for the compiler,

This is just plain wrong.

Compilers cannot just introduce new keywords, they have to live in many
environments.  Therefore they have to be extra careful and use appropriate
prefixes etc.  The llvm people don't care so why should anyone else?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=11157

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[truls dot becken at gmail dot com]

------- Additional Comments From truls dot becken at gmail dot com  2010-01-25 21:36 -------
This is an absolutely ridiculous attitude. The C standard (section 17.4.3.1.2) reserves identifiers that start with an 
underscore for the implementation. There are two cases when it is acceptable to use them:
 - As public symbols exported by libc.
 - As keywords for non-standard compiler extensions.

By convention, double underscores are reserved for the compiler, single underscores for the libc. All C compilers add 
extensions that begin with double underscores. GCC defines some like __asm, Microsoft's C compiler defines some for 
SEH, Clang supports most of the GCC ones and __block.

Using them as parameter names in the header is entirely wrong and is not guaranteed to work on any standards-
compliant compiler. If glibc exported a __block function or global variable, then your attitude would make sense, but 
you are using __block as an identifier in a context that is explicitly not supported by the standard.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=11157

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11157] __block is a reserved word with clang -fblocks

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2010-01-15 07:34 -------
Then don't use it.  It is not acceptable that compilers steal identifiers.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://sourceware.org/bugzilla/show_bug.cgi?id=11157

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.