[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: 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


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 
(, while 
in the special case of linux a FILE object is a buffering object around a file 
descriptor (
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>"
  # 2 "<stdin>" 3 4
  # 2 "<stdin>"

While in cygwin:

  $ printf "#include <stdio.h>\nint stdin;\n" | gcc -E - | tail -n6
  # 2 "<stdin>"
  # 2 "<stdin>" 3 4
  # 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.

 - assaf

reply via email to

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