Another aspect of this issue is the max length of bytes to/from a DLL. In this post I was asking that the documentation be updated from saying the old limit of '900', instead of making it clear that this also involved a GPF crash bug. But instead of changing the 900 to indicate the updated limit, the reference to the 900 limit was deleted.

It appears the string sent to the DLL is chopped at maxlenl+100 the same way other identifiers are having their parms chopped at that same length, however if the string returned from the DLL back to mIRC is longer than RETURN-LIMIT bytes, it crashes the client.

I encountered the crash bug in a DLL where I was making an extension of the $rand(a,z) function where I could have a 3rd parm which indicates the number of random bytes within the range to output. i.e. $rand(a,z,10) would return 10 random letters. I was limiting the output to be $maxlenl characters, and everything was fine as long as 'z' was replaced by a codepoint <= 2047 where each codepoint is UTF8 encoded as 1 or 2 bytes. However, when 'z' and 'a' were both replaced by a codepoint above 2047, it was easy to make the DLL crash. It appears that RETURN-LIMIT is close to ( ($maxlenl + grace-length) x 2 + 100), and if the DLL sends more than RETURN-LIMIT bytes back to mIRC, that triggers the GPF.

When sending codepoints which UTF8-encode into 3 bytes, I was able to safely send the following strings from the DLL, but increasing the string by +1 character, the GPF crashed mIRC.

v7.63, $maxlenl 10240 + grace-length 100 = 10340
safe = 6927*3 = (10240+100)*2+101

v7.61, $maxlenl 8192 + grace-length 100 = 8292
safe = 5563*3 = (8192+100)*2+105

v7.51, pre-$maxlenl 4096 + grace-length 54 = 4150
safe = 2800*3 = (4096+54)*2+100

Is there a memory structure which a DLL can look at to see what's the safe byte length to output back to mIRC, or should the documentation just be updated to indicate the max safe bytes whether or not the buffer is bumped up to be 3*(maxlenl+grace)?