[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:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02
"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: qemu.org | libvirt.org