1. Starting with the prior beta, files containing only 0x00 bytes formerly returned $lines = 1, regardless of the count, but now they always return zero.
This case is more realistic than the next one, as I see it possible for scripts to assume that the only time $Lines=0 was when the filesize was zero or the file didn't exist, as the lines=1 goes back to 6.35.
//var %file test.dat | bset &v 1 $str(0 $chr(32),$rand(1,9)) | bwrite -c %file 0 9 &v | bread %file 0 9 &v | if (!$lines(%file)) echo 4 -a %file missing or size zero: contents: $bvar(&v,1-) lines: $lines(%file) filesize: $file(%file).size
2. For $lines, files with 2^31 thru 2^32 lines now return zero instead of negative signed integers. With lines > 2^32, it now returns (linecount mod 2^32).
It's probably excessive to support the high line counts, and I don't know if the API returns signed int32's or whether that's an internal choice where a change to uint32 would bump up the range of valid lines. It shouldn't need to use a larger variable and slow everyone down for the edge case above 2^32. The speed is much improved, taking minutes vs hours.