There is no discussion about this being a bug or not Talon, you can put it any way you want, this is a bug, while not explicitely stating it's a bug, Khaled, by not saying it's not a bug, agreed with this.
What you seem to have missed is that there is also no discussion about why these \0 are here, you spent multiple hours on IRC explaining why, but it's not difficult to understand why, I know why, you know why, Khaled knows why, Sat knows as well.
Your example is not showing anything, yes 4 bytes is 4 bytes, these can be 0 48 or 125, it doesn't matter.

These \0 weren't sent, I should not get them, end of the story. If mIRC wanted to replace newline sequence by \0 in this case because it was very convenient, that's fine, but now if it puts these non received bytes into my binvar, it's a huge problem.
If I get \x20\x00\x00, what is the line that was sent? was it \x20\x13\x10? was it \x20\x00\x10 ?
If I were to decode utf8 from the bytes I get, it would make it invalid utf8 sequences
But just this: the data I'm getting is corrupted.

I'm not the one not understanding and I don't understand why you refuse to get it; because the behavior can be explained does not make it a correct behavior.
Please don't make another post about this. @Khaled, if you could tell him this is incorrect behavior, regardless of if you are going to fix it, that would be nice.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel