Forums Bug Reports sockread, 'line' and nul byte (0)

I'm not sure this is a bug.
When /sockreading, mIRC does not consider nul bytes as the ending of the line, indeed /sockread %var won't read anything if the following bytes are sent for example:
Therefore sockread -f %var should read all those bytes, or at least I think one would assume it would, since sockread %var didn't consider them as ending the line.
/sockread -f will only read up to the nul byte.
This can be problematic if you use on sockclose to read the last line assuming on sockread took care of all the previous lines, with a typical loop on $sockbr, although a script could easily do that loop again inside on sockclose.
Is it normal bebavior for /sockread -f to stop at nul byte?

I think you'll find that all text identifiers choke on null bytes, seems if you expect null bytes you should be using binary variables.

I was just helping splinny with this https://forums.mirc.com/ubbthreads.php/topics/253314/Re:_I_need_help_retrieving_tex#Post253314 , not expecting anything

Identifiers and socket are very different, if sockread %var doesn't take nul byte as the end of the line, then sockread -f should, especially when you read the help file:
Now, of course the help file is wrong, only $lf is a delimiter of newline, $cr being removed automatically, (I made some report about that already), but if this is intentional the help must be updated, because it currently does not fill the variable with whatever text is in the receive buffer.

mIRC won't fill a var with a null byte no matter where it comes from.

//bset &b 1 44 0 44 | var %bvar $bvar(&b,1-).text | echo -ag %bvar $len(%bvar) | bwrite test.txt -1 -1 &b | var %read $read(test.txt) | echo -ag %read $len(%read) | var %char $chr(44) $+ $chr(0) $+ $chr(44) | echo -ag %char $len(%char)

If there's a null byte, you can't use text variables or pass it as text in any way. It's not related specifically to sockets. Every single command and identifier that deals with text will not handle the null byte. /sockread -f %var should not be changed to handle null bytes, you should be using binary variables.

I know that, I'm not necessarily asking for a change in the behavior, I'm asking about the behavior and its documentation.
You don't see the handling of nul byte being described for identifiers and commands but the help file for sockread -f
specifically indicate how it will work, and it implies that nul byte will be read so that's quite wrong, so yes this issue is specically related to socket. Also, your example with $chr(0) only shows $chr(0) is being ignored, which could have been the case for /sockread -f for example

Yes, this is the intended behaviour. As all text is terminated with a NULL byte, if you attempt to read binary data that contains NULL bytes into a text variable, /sockread -f %var will only be able to read up to the NULL byte. You would either need to loop on $sockbr to make sure the whole buffer is read or use a &binvar if you are expecting binary data.

Yeah, so you don't think it's worth adding something about this to the help file?

Well, any programmer/scripter who comes across this should already know what is happening, ie. that they are trying to parse binary data as text and that text is terminated by a NULL. However, I will add a note to /sockread -f stating that NULLs cannot be parsed.