sed-devel
[Top][All Lists]
Advanced

[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




reply via email to

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