On Thu, Jun 11, 2015 at 9:54 AM, Hans-Werner Hilse <hwhi...@gmail.com> wrote: > 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)."
Yeah, but we're talking about structure members. > 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." So, what exactly is the build error you're facing and how can I reproduce? -- Thanks, //richard ------------------------------------------------------------------------------ _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
