0x1a bug - its not just awk

Gareth Williams dgwilliams@dera.gov.uk
Mon Nov 22 12:38:00 GMT 1999

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

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.


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

$ 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.


More information about the Cygwin mailing list