Message-ID: <3EBF8E05.3050102@lml.ls.fi.upm.es>
Date: Mon, 12 May 2003 14:05:25 +0200
From: Manuel Collado <m DOT collado AT aaron DOT ls DOT fi DOT upm DOT es>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: gawk 3.1.1: bug in stdout redirection on WinNT 4.0
References: <3EB7C0D6 DOT 7030206 AT lml DOT ls DOT fi DOT upm DOT es> <9003-Tue06May2003200634+0300-eliz AT elta DOT co DOT il> <3EB8F9A6 DOT 4050307 AT lml DOT ls DOT fi DOT upm DOT es> <2427-Wed07May2003165629+0300-eliz AT elta DOT co DOT il> <3EBA4A19 DOT 9090902 AT lml DOT ls DOT fi DOT upm DOT es> <7458-Thu08May2003190131+0300-eliz AT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 138.100.10.20
X-Trace: 12 May 2003 14:02:43 +0100, 138.100.10.20
Lines: 114
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
>>...
>>>Redirection from the command line has nothing to do with Gawk (or any
>>>DJGPP program).  The redirection is done by the shell you are using,
>>>either Bash or CMD.EXE.  It's possible that CMD.EXE from NT4 has
>>>problems with redirection when it runs DOS programs (I think I've
>>>heard in the past a couple of reports along these lines, but I'm not
>>>sure).
>>
>>Yes, this is what puzzles me. But the fact is that gawk 3.0.6 behaves 
>>correctly. And also other DJGPP ported utilities that write to stdout.
>>
>>Thinking about possible causes, I'm considering the following possibilities:
>>
>>- The ported gawk 3.1.1 code makes some test on the stdout handler and 
>>resets the file pointer in some circumstances.

Confirmed (see below).

>>
>>- The same action is performed at the library level.

Someway, yes (see below).

> 
> 
> Then how come the same Gawk works with Bash as the shell?
> 
> Perhaps the redirected handle is set up by CMD.EXE so that the
> overwriting results?  I'm just stabbing in the dark here...
> 
> 
>>Before looking at the sources or further investigation, I would like to 
>>know if there is a way to know which library version has been used to 
>>build each particular version of gawk.
> 
> 
> It's not easy.  Try "strings gawk.exe" and look at the string "DJGPP
> libc".  But some people have their libraries patched without updating
> the library version string...

Thanks. It seems that gawk 3.1.1 uses the current libc.a from DJGPP v2.03.

> 
> 
>>I could also try to rebuild gawk from the sources. But in that case I 
>>would like to use exactly the same library version.
> 
> 
> You could use stock v2.03 and the alpha version of v2.04, and compare
> the results.

I think I've partially diagnosed the problem. After that, I've been able 
to reproduce the bug from scratch. Here is it:

1. Rebuild gawk 3.1.1 from sources by using gcc 3.2, djgpp v2.03. Bug 
persists.

2. Look at the code. Found gawk initialization code that checks std 
handlers for sanity by calling fstat. This code doesn't exist in gawk 3.0.6.

3. Disable the handlers check. Rebuild. Bug gone!

4. Try to reproduce the bug from scratch. Done by borrowing part of the 
initialization code from gawk 3.1.1. The following minimal program 
reproduces the bug:

F:\PRUEBAS\DJGPP>cat appbug.c
#include <stdio.h>
#include <time.h>
#include <sys/stat.h>

main(){
    struct stat sbuf;
    int fd;

    char tx[]="bbbb\n";

    if (fstat(1, &sbuf) < 0) {
       tx[1]='x';
    }

    printf (tx);
}

F:\PRUEBAS\DJGPP>cat apptest.bat
@echo off
echo aaaaaaaaaaaaaaaaaaaaaaa > out.txt
appbug >> out.txt
echo -----------------------
type out.txt
echo -----------------------

F:\PRUEBAS\DJGPP>apptest
-----------------------
bbbb
aaaaaaaaaaaaaaaaa
-----------------------

This program has been tested on WinNT 4.0 SP5/SP6, and Win2000 (no SP), 
  using cmd.exe as shell, with the same results.

Using bash as a shell lets the program behaves correctly. Apparently 
there is an obscure flaw in NT output redirection, that is uncovered by 
the complex code of fstat in some circumstances.

I'll try to repeat the test with the new djgpp v2.04 alpha version, if I 
can find some spare time (no promises).

Thanks,
-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado