Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

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

Charles Dye

Super Moderator
May
4,948
126
Staff member
Code:
@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.
 
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.
 
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).
 
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!
 

Similar threads

Back
Top