From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kp2wz-000803-Dj for qemu-devel@nongnu.org; Sun, 12 Oct 2008 11:33:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kp2wx-0007yL-8R for qemu-devel@nongnu.org; Sun, 12 Oct 2008 11:33:44 -0400 Received: from [199.232.76.173] (port=37631 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kp2wx-0007yI-4u for qemu-devel@nongnu.org; Sun, 12 Oct 2008 11:33:43 -0400 Received: from mail2.shareable.org ([80.68.89.115]:51965) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kp2ww-00042K-P3 for qemu-devel@nongnu.org; Sun, 12 Oct 2008 11:33:43 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Kp2wt-00052x-Ad for qemu-devel@nongnu.org; Sun, 12 Oct 2008 16:33:39 +0100 Date: Sun, 12 Oct 2008 16:33:39 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [5466] Only use __builtin_* with GCC >= 3.4 Message-ID: <20081012153339.GC18814@shareable.org> References: <48F1EE9B.6040706@redhat.com> <20081012142348.GA18814@shareable.org> <48F21193.3000809@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48F21193.3000809@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Avi Kivity wrote: > It's illegal to define or use an identifier beginning with two > underscores, unless it's documented by the implementation. What if > glibc adds a third argument? All your apps wil break. > > You should define your own macros for this, with a non-__ name. I agree. Portable apps especially should use their own names. Same applies with just one underscore, I think: they're reserved in the "implementation" namespace. But I'd add that avoiding underscore is advisable but not a guarantee. Sometimes Glibc defines a new macro/variable/function _without_ the preceding underscore, when you've requested all Glibc extensions by defining _GNU_SOURCE. It's not likely for this macro, and conflicts are obviously much more likely with underscore prefixes. I've also seen ugly link-time or run-time errors: E.g. defining a function called `dprintf' or `warn' in the app can break some parts of Glibc at run-time, with no compile-time error. This is awkward for third party _libs_ used with a lot of other libs and apps, as the only realistic protection comes from making sure every non-static symbol (including internal-use-only ones) has a prefix that no other lib or app is likely to use. Fingers crossed. Once you're dependent on prefix uniqueness, it's a matter of debate or maybe taste whether using `_myownlib_symbol' (i.e. underscore prefix before unique prefix) is advisable for internal-use-only names. -- Jamie