Fixed TYPE /X reports FF for all values >= 80h

[Charles Dye]

@echo off
setlocal

set bb=%@balloc[256]
for /l %i in ( 0, 1, 255 ) set rv=%@bpoke[%bb,%i,1,%i]

set filename=testfile.dat
set handle=%@fileopen[%filename,w,b]
set rv=%@bwrite[%bb,0,%handle,0,256]
set rv=%@fileclose[%handle]
set rv=%@bfree[%bb]

type /x %filename
del /q %filename

endlocal

TCC v13.04.57 and v12.11.76 both report FF for all values with the top bit set. TCC v11.00.52 works as expected.

 

[Steve Fabian]

TCC v13.04.57 and v12.11.76 both report FF for all values with the top bit set. TCC v11.00.52 works as expected.

Report verified here for all three versions. 32b versions.
--
Steve

 

[Charles Dye]

Another, possibly related, oddity: If the file begins with FFh FEh, then bytes greater than 7Fh are displayed correctly, but the first two are silently dropped: appropriate when dumping a file as UTF-16 text, but not when dumping it as a series of bytes.

 

[rconn]

TCC v13.04.57 and v12.11.76 both report FF for all values with the top bit set. TCC v11.00.52 works as expected.

Fixed in build 13.04.58. (An unexpectedly demented compiler macro that I'll never use again!)

 

[rconn]

Another, possibly related, oddity: If the file begins with FFh FEh, then bytes greater than 7Fh are displayed correctly, but the first two are silently dropped: appropriate when dumping a file as UTF-16 text, but not when dumping it as a series of bytes.

WAD. Unicode BOMs are always removed (long before) files are read (& displayed in the case of HEAD / TAIL / TYPE). Changing that requires either a complete parser rewrite, or simply removing the /X option from TYPE.

And TYPE /X does not display a Unicode file as a series of bytes, it displays it as a series of characters (two bytes per character).

 

[Charles Dye]

Fixed in build 13.04.58. (An unexpectedly demented compiler macro that I'll never use again!)

How you figure these things out I will never understand. I get confused enough chasing down my own bugs!

 

[Charles Dye]

Bug squashed in build 59. Thank you, Rex.