mIRC Home    About    Download    Register    News    Help

Print Thread
$maxlenl chars vs bytes #265243 22/03/19 04:20 AM
Joined: Jan 2004
Posts: 1,173
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,173
I'm unsure if this is by design or is a bug, but there's at least 1 bug in here. Sometimes $maxlenl means 'characters' and other times 'bytes'.

Not an error: //echo -a $str($chr(10004),8280) $+ x is 24841 bytes

but other string functions are silently ignoring characters beyond the byte length. Both output the same hash:

//echo -a $sha256($str($chr(10004),2764))
//echo -a $sha256($str($chr(10004),2765))

i.e. 2764*3=8292

same happens with: $md5 $sha1/256/384/512 $crc $hmac $hotp $totp
but not with $hash

bset does not return an error, but limits bytes added to a &binvar at 8292:

//bset -t &v 1 $str($chr(10004),6000) | echo -a $bvar(&v,0) $sha256(&v,1)

result: 8292 (hash for 2764 UTF8 characters)

but /write can output a variable containing 8270 10004's.

$len doesn't report a number larger than 8292, and there's no line-too-long error:

//echo -a $len($utfencode($str($chr(10004),3000)))

It also appears that mIRC can receive a byte string from a DLL somewhat longer than double the 8292 bytes without crashing, but it doesn't appear that mIRC can send more than 8292 bytes worth of unicode characters to a dll. This is related to my question here

Re: $maxlenl chars vs bytes [Re: maroon] #265244 22/03/19 07:42 AM
Joined: Dec 2002
Posts: 4,519
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,519
The maximum internal length applies to both byte arrays and wide character arrays throughout mIRC. If you are dealing with strings, it means characters. If you are dealing with binary variables, it means bytes. That said, this may not apply everywhere, and if you are converting back and forth between strings and binary variables, longer lengths may be preserved, but that is not guaranteed.

Regarding $len(): it has no checks on string length - it is returning the length of the string that it is seeing. The issue is with $utfencode() which was originally designed to quietly truncate results at the maximum length. This actually has been discussed before - while it would be possible to change it to report errors, the odds are that this would break scripts. The same applies to many old identifiers that truncate quietly.

In your example, $utfencode() is creating a truncated string of 8292, which is beyond the maximum allowed string length of $maxlenl. The scripting language allows you some leeway but your string is at the very maximum of the leeway. At this point, use of the string may cause a string length error at some point in the scripting language, depending on how the string is used.