Bug 11157

Then don't use it.  It is not acceptable that compilers steal identifiers.

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.

(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?

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.

> 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.

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

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.

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.

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.

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