Re: [uml-devel] [PATCH 2/3] um: Do not use stdin and stdout names for variables

[Hans-Werner Hilse <hwhilse@gmail.com>]

Am 2015-06-11 08:49, schrieb Richard Weinberger:
> On Thu, Jun 11, 2015 at 8:35 AM, Hans-Werner Hilse <hwhilse@gmail.com> 
> wrote:
>> Hi,
>> 
>> Am 2015-06-10 23:37, schrieb Richard Weinberger:
>>> On Wed, Jun 10, 2015 at 11:21 PM, Hans-Werner Hilse 
>>> <hwhilse@gmail.com>
>>> wrote:
>>>> Naming local variables "stdin" and "stdout" is fine with glibc,
>>>> other C libraries, namely musl, will however complain.
>>> 
>>> Wait, what?!
>>> These are not local variables, they are struct members.
>>> 
>>> What exactly is the issue with musl? Sounds very odd.
>> 
>> They chose to have stdin and stdout (and, of course, stderr) wrapped 
>> in
>> macros - in a different way than glibc:
>> 
>> [...]
> 
> Slow down a bit. Since when is it forbidden to name something "stdin" 
> in a C
> program? Does the standard say that? If yes, where?
> We have to sort this out. If UML violates a rule, we have to fix it.
> But maybe musl needs fixing...

Digging further, I think I cannot better describe the issue than Rich 
Felker did in this message:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130506/173690.html

> Per ISO C, stdin, stdout, and stderr are macros "which are expressions
> of type ''pointer to FILE'' that point to the FILE objects associated,
> respectively, with the standard error, input, and output streams."
> (C99 7.19.1 paragraph 3). They are not necessarily objects, merely
> expressions, and as such, taking their address is invalid.

That last sentence, however, does not apply to the problem I'm facing 
with UML and musl. Here, the problem is actually that the 
stdin/stdout/stderr identifiers are per the C standard predefined as 
being macros.

In the glibc case, it won't break anyway since the macro definition is 
tight enough to mask the problem. For musl, the macro definition is 
minimally more complex and the result is a macro expansion that leaves 
syntactically incorrect code. In the past - see the linked discussion - 
musl developers stressed that their implementation is conformant to the 
standard.

About forbidden use of names/identifiers from the stdlib, the C standard 
is a bit hard for me to grasp fully. However, I think C99 7.1.3 
paragraph 1, 3rd point is relevant here: "Each macro name in any of the 
following subclauses (including the future library directions) is 
reserved for use as specified if any of its associated headers is 
included; unless explicitly stated otherwise (see 7.1.4)."

So aside from renaming struct members, another option would be to lift 
the macro definition by an "#undef" in relevant places. I have a 
feeling, though, that this faces new problems with the C99 standard, 
7.1.3 paragraph 3, which says that "If the program removes (with #undef) 
any macro definition of an identifier in the first group listed above, 
the behavior is undefined."

-hwh


------------------------------------------------------------------------------
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel