When compiling a project with Clang, and specifying the -fblocks flag, __block becomes a reserved world.
The declaration of function encrypt() in unistd.h uses __block as the name of one of its arguments, so the
compiler gives an error when parsing this header file.
Then don't use it. It is not acceptable that compilers steal identifiers.
This is an absolutely ridiculous attitude. The C standard (section 18.104.22.168.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?
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
- 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
> 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
> 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
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'.
# undef __block
# include_next "unistd.h"
# define __block __attribute__((__blocks__(byref)))
# include_next "unistd.h"
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 <email@example.com>
* crypt/crypt.h, posix/unistd.h: Use __libc_block instead of
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.
Author: Meador Inge <firstname.lastname@example.org>
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 . This patches takes that