Re: [git pull] x86 updates for v2.6.28, phase #1

[malc@pulsesoft.com]

"H. Peter Anvin" <hpa@zytor.com> writes:

> 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.

C++ side of things FWIW

17.4.3.1.2   Global names [global.names]

          -- Certain sets of names and function signatures are always
             reserved to the implementation:
          -- Each name that contains a double underscore __ or begins
             with an underscore followed by an uppercase letter (2.11)
             is reserved to the implementation for any use.

That's from "Working Draft, Standard for Programming Language C++"
n2315.pdf.

>>> 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

I was always wondered why Linux was so bent on starting a lot of
identifiers with double underscores, but then settled on the thought
that it's kernel and sort of special in that regard (no need to follow
every single word of the C standard), but it doesn't really explain
why all Linus' projects i came across are full of them (git, sparse)

-- 
mailto:av1474@comtv.ru