Re: [compile error] execute.c b/c local variable 'stdin' in 'debug_print_input '

[Eric Blake]

On 11/1/18 2:54 PM, Eric Blake wrote:

> "Applications shall not declare or define identifiers with the same name 
> as an identifier reserved in the same context."
>
> Thus, I read it that if we included <stdio.h>, the name 'stdio' is 

the name 'stdin'

> reserved for use as the external identifier, which means the 
> implementation is free to implement a macro by that name, and our 
> attempt to shadow the name without using #undef is a bug in our part, 
> and not in the headers for using a macro.
>
> > The cygwin case expands the 'stdin' macro and results in invalid C code.
>
> Rather, the C code got lucky on glibc with it's incorrect use of a 
> reserved name for a non-reserved purpose not actually colliding, but 
> failed on Cygwin due to a clash in definitions where the fault lies in 
> the application and not in the system headers.
>
> > Then again, this is just splitting hairs. Your suggestion is good and
> > I'll commit the patch soon.
>
> Yes, the patch to use a non-reserved name is ideal in any case.

One more point - a local variable shadowing an identifier with external 
linkage does not necessarily conflict - so let's check one more piece of 
information in the standards:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.html#tag_13_49

"The <stdio.h> header shall define the following macros which shall 
expand to expressions of type "pointer to FILE" that point to the FILE 
objects associated, respectively, with the standard error, input, and 
output streams:

stderr
    Standard error output stream.
stdin
    Standard input stream.
stdout
    Standard output stream."

The fact that the standard requires 'stdin' to be a macro, and does not 
require the macro to expand to merely a single identifier, is good 
evidence that you should not attempt to shadow it.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org