Am 2015-06-11 08:49, schrieb Richard Weinberger: > On Thu, Jun 11, 2015 at 8:35 AM, Hans-Werner Hilse <hwhi...@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 >>> <hwhi...@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
