[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [compile error] execute.c b/c local variable 'stdin' in 'debug_print_input '
Date: Thu, 1 Nov 2018 14:54:09 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 11/1/18 2:16 PM, Assaf Gordon wrote:

I agree with your description of stdin, but I still think the problem
is in msys2/cygwin and not in gnu/linux.

When 'stdin' is defined as a variable, there should be no problem
in redefining it as another type in a local variable, eg.:

    int a;
    void foo()
       double a;

And similarly:

    extern FILE *stdin;
    void foo()
       bool stdin;

(as a side note:new gcc warning such as 'shadowing global variable'
might warn about such cases, but it's not a C error).

Being -Wshadow clean is a nice goal, but you're right that shadowing is permitted by C.

The problem arises when stdin is not a variable, but a macro
definition, as is the case in cygwin (and I assume in msys2):

    #define stdin   (_REENT->_stdin)

Then, code like "bool stdin" becomes un-compilable.

The question at hand, then, is whether the bug lies in the system (for defining a macro) or in the local code (for using a name reserved for the system to define as a macro). Checking the standards:

"All identifiers in this volume of POSIX.1-2017, except environ, are defined in at least one of the headers, as shown in XBD Headers. When [XSI] [Option Start] _XOPEN_SOURCE or [Option End] _POSIX_C_SOURCE is defined, each header defines or declares some identifiers, potentially conflicting with identifiers used by the application. The set of identifiers visible to the application consists of precisely those identifiers from the header pages of the included headers, as well as additional identifiers reserved for the implementation. In addition, some headers may make visible identifiers from other headers as indicated on the relevant header pages.
"Each identifier with external linkage described in the header section is reserved for use as an identifier with external linkage if the header is included.
"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 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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]