mIRC Home    About    Download    Register    News    Help

Print Thread
#266687 12/01/20 10:20 PM
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
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.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report.

The first issue: it looks like the beta is returning the correct result. So this is essentially a backward compatibility issue for scripters who use $lines() on binary files that contain only 0x00 bytes to determine whether they are empty or not. Hmm.

The second issue: overflows are tricky because signed 32bit INTs are used in almost every feature. I might be able to check for this in the core line counting routine though.


Link Copied to Clipboard