Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <3.0.6.32.19991122203517.00924d50@146.80.9.11>
X-Sender: dgwilliams AT 146 DOT 80 DOT 9 DOT 11
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Mon, 22 Nov 1999 20:35:17 +0000
To: cygwin AT sourceware DOT cygnus DOT com
From: Gareth Williams <dgwilliams AT dera DOT gov DOT uk>
Subject: 0x1a bug - its not just awk
CC: gareth AT dgwsoft DOT co DOT uk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_943302917==_"

--=====================_943302917==_
Content-Type: text/plain; charset="us-ascii"

I just downloaded B20.1 and compiled a few C++ programs under NT4.
Those that write data work fine. Those that read fail on the byte
0x1a.

I have seen the reports that awk can not read the byte 0x1a.

Well, the problem is not with awk. "cat" can't read it. 
"cin.get(c)" can't read it. However cp can copy it. And it is
OK reading from a pipe, just not from a file.

Attached:

bytesout.cpp:   writes out 10 bytes with 0x1a the 7th byte.
bytesin.cpp:    reads bytes, prints them and gives a count

(compiled with g++: g++ -o x x.cpp)

This happens:

$ bytesout > tmp             ## produces a 10 byte file
$ bytesin < tmp              ## produces a count of 6 bytes
$ cat tmp > tmp2             ## produces a 6 byte file

but
$ bytesout | bytesin         ## reports 10 bytes
$ bytesout | cat | bytesin   ## reports 10 bytes
$ cp tmp tmp2                ## produces a 10 byte file

If you put the 0x1a in different places it does what you
expect (fails on that byte) except if 0x1a is the second
byte it reads zero bytes.

So I would guess the problem is in some low-level I/O
routine that is used by fstream, and by cat, but not by cp.

PS I am a first time user of CYGWIN and was very impressed
by the ease with which I could port my C++ project
(developed with egcs on SGI and Linux) to NT, even though rather
bemused by this strange bug.

cheers


--=====================_943302917==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="bytesin.cpp"


#include <iostream>

main()
{
    char c;
    int i = 0;

    while ( cin.get(c) )
    {
        ++i;
        cout << int(c) << endl;
    }

    cerr << i << " bytes read" << endl;

}
--=====================_943302917==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="bytesout.cpp"


#include <iostream>

const int ASIZE = 10;
const unsigned char A[ASIZE] =
           { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x1a, 0x1b, 0x1c, 0x1d };

main()
{
    for (int i=0; i<ASIZE; i++)
    {
        cout << A[i];
    }
}
--=====================_943302917==_
Content-Type: text/plain; charset="us-ascii"



--
Gareth Williams <dgwilliams AT dera DOT gov DOT uk>        +44 (0)1684 894118
A709 DERA Malvern, St Andrews Rd, MALVERN, Worcestershire, England.

--=====================_943302917==_
Content-Type: text/plain; charset=us-ascii

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
--=====================_943302917==_--