From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31285 invoked by alias); 8 Jun 2010 07:40:21 -0000 Received: (qmail 31138 invoked by uid 48); 8 Jun 2010 07:39:58 -0000 Date: Tue, 08 Jun 2010 07:40:00 -0000 Message-ID: <20100608073958.31137.qmail@sourceware.org> From: "bonzini at gnu dot org" To: glibc-bugs@sources.redhat.com In-Reply-To: <20100110175229.11157.truls.becken@gmail.com> References: <20100110175229.11157.truls.becken@gmail.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/11157] __block is a reserved word with clang -fblocks X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00081.txt.bz2 ------- 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 #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.