From: "H. Peter Anvin" <hpa@zytor.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [git pull] x86 updates for v2.6.28, phase #1
Date: Fri, 10 Oct 2008 14:21:57 -0700 [thread overview]
Message-ID: <48EFC775.9090900@zytor.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0810101358480.3503@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>
> Yeah. If I recall the namespace rules correctly, you have to have a
> underscore followed by another underscore or an upper-case letter. Those
> cannot even be used for local variables by a conforming program.
>
> Single-underscore + lower-case letter is only reserved as an external
> identifier. I _think_.
Strictly speaking, they are "reserved for identifiers with file scope in
both identifier and tag space" (POSIX.1-2004, xsi § 2.2.2, lines 718-).
> So a conforming program could still do
>
> int main(int argc, char **argv)
> {
> int _asm_x86_types_h = 1;
> return _asm_x86_types_h;
> }
>
> and I _think_ it should be ok.
Correct.
> So a system macro definition that could mess with something (admittedly
> crazy as that) has to be either double underscores or underscore +
> uppercase, so as long as the prefix is "_ASM" (or _LINUX), we're ok.
>
> Double underscores in the _middle_ of the identifiers are a non-issue, and
> are just ugly.
Double underscores when used in external identifiers (not an issue here)
can conflict with some C++ mangling schemes, in particular the old
Cfront scheme (which had to be compatible with a standard C compiler.)
gcc seems to use another scheme, but it doesn't either appear to include
any non-C characters, which means it's at least theoretically possible
to step on its toes.
>> That being said, I don't personally like the double underscores.
>
> I agree, inside the identifier in particular they do seem pointless. At
> the beginning, they are useful for things like __i386__ or __x86, where
> you need the double underscore because 'i' is lower-case.
>
> Or maybe I mis-remember the name space rules.
No, you're right on track.
There is an additional rule, which is _de_facto_ since it is out of
scope for the standards: identifiers of the form __foo__ (double
underscores at the start *and* end) are often considered reserved for
the *compiler*.
-hpa
next prev parent reply other threads:[~2008-10-10 21:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 23:47 [git pull] x86 updates for v2.6.28, phase #1 Ingo Molnar
2008-10-10 15:15 ` Linus Torvalds
2008-10-10 15:26 ` Ingo Molnar
2008-10-10 15:58 ` Ingo Molnar
2008-10-10 20:39 ` Vegard Nossum
2008-10-10 20:43 ` H. Peter Anvin
2008-10-10 21:07 ` Linus Torvalds
2008-10-10 21:21 ` H. Peter Anvin [this message]
2008-10-10 21:37 ` malc
2008-10-10 20:47 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48EFC775.9090900@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.