Hi, 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. Best regards, Truls
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