[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: |
Assaf Gordon |
Subject: |
Re: [compile error] execute.c b/c local variable 'stdin' in 'debug_print_input ' |
Date: |
Thu, 1 Nov 2018 13:16:57 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
Hello,
On 2018-11-01 10:40 a.m., Jannick wrote:
On Thu, 1 Nov 2018 10:15:04 -0600, Assaf Gordon wrote:
I assume it's an issue specific to the definition of 'stdin' in
windows/msys2, as there is no compilation issue with gcc-8.2 on linux.
Just digging into that a bit and I think it is rather the other way round:
stdin - together with stdout and stderr - is of type FILE* according to POSIX
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html), while
in the special case of linux a FILE object is a buffering object around a file
descriptor (http://man7.org/linux/man-pages/man3/stdin.3.html).
So linux happened to not complain about the type collision I ran into.
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).
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.
This can be demonstrated by examining the output of the
preprocessor. In GNU/Linux:
$ printf "#include <stdio.h>\nint stdin;\n" | gcc -E - | tail -n6
# 2 "<stdin>"
int
# 2 "<stdin>" 3 4
stdin
# 2 "<stdin>"
;
While in cygwin:
$ printf "#include <stdio.h>\nint stdin;\n" | gcc -E - | tail -n6
# 2 "<stdin>"
int
# 2 "<stdin>" 3 4
((__getreent())->_stdin)
# 2 "<stdin>"
;
The cygwin case expands the 'stdin' macro and results in invalid C code.
---
Then again, this is just splitting hairs. Your suggestion is good and
I'll commit the patch soon.
regards,
- assaf