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.
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).
How you figure these things out I will never understand. I get confused enough chasing down my own bugs!
