mIRC Homepage

$chr(160) bug - I found the reason :)

Posted By: TimeFX

$chr(160) bug - I found the reason :) - 04/06/04 04:18 PM

I had the same chr(160) bug as reported before.
To avoid this bug go to settings > "IRC" > "Messages" and turn off the "SJIS/JIS conversion".

Please fix grin


TimeFX
Posted By: Aoshi

Re: $chr(160) bug - I found the reason :) - 04/06/04 10:56 PM

Well this solution solved my problem, but its weird tho.

When I was writing normal text, no colours, in a Channel with +c turned on I often got the message: Can not send to Channel.

Well I don't know excactly for what $chr(160) stands but I think it shouldn't be on normal text smile
Posted By: kibou

Re: $chr(160) bug - I found the reason :) - 05/06/04 11:52 AM

160 is the ASCII number for a no break space.
Posted By: argv0

Re: $chr(160) bug - I found the reason :) - 05/06/04 05:24 PM

quite untrue, chr 160 is not a "defined" key, its different on many fonts and shouldnt be trusted as a reliable 'nbsp'
Posted By: Sais

Re: $chr(160) bug - I found the reason :) - 05/06/04 06:53 PM

It would appear that 160 (0xA0) is the start marker for one of the ranges of double-byte symbols in (S?)JIS.

I would hazard a guess that if you then put an 'invalid' second byte after it, something in the code is throwing a wobbly. This, of course, is a _lot_ of assumption. I don't know what Khaled's code does with input multibyte chars; how it handles them. I also only have a passing awareness of how double-byte CJK (SJIS, BIG5, etc) actually encode the characters.
Posted By: Danthemandoo

Re: $chr(160) bug - I found the reason :) - 05/06/04 06:57 PM

i can confirm that with the option enabled, my mirc crashes with a $chr(160) in an ame, but with it disabled, it works fine.
Posted By: Zyzzyx26

Re: $chr(160) bug - I found the reason :) - 05/06/04 07:04 PM

I've read a few threads about the $chr(160) bug, but i still don't know what you ppl are talking about :P

What do you mean by no break space? Where this $chr has to be so mIRC crashes?

Thanks laugh

Zyzzyx.
Posted By: Sais

Re: $chr(160) bug - I found the reason :) - 08/06/04 12:26 AM

go to alt-o IRC->messages, enable SJIS/JIS conversion

now :

Code:
 //say $chr(160)  


(you need to be connected to a server)
Posted By: Zyzzyx26

Re: $chr(160) bug - I found the reason :) - 08/06/04 12:34 AM

Oh, i see smile But what's the difference between the $chr(160) and $chr(32)?

Thanks for the help smile

Zyzzyx.
Posted By: Sais

Re: $chr(160) bug - I found the reason :) - 08/06/04 12:48 AM

160 and 32 are different ascii characters!

32 (0x20) is SPC - a normal, common or garden space.
160 (0xA0) is often a "non-breaking" space (one which wouldn't be the 'breaking point' of a line wrap). In other fonts it isn't - so sometimes you'll get the 'no chatacter to see here' back box. In SJIS, it is used as the start marker for one 'series' of two-byte characters.

SJIS is a form of Japanese encoding based on JIS (ISO 2022) which uses a mix of single and double-byte sequences to represent normal ascii, and Japanese (or CJK: Chinese-Japanese-Korean) characters. Particular escape sequences define the transition between normal ascii and Japanese encoding.
Posted By: Zyzzyx26

Re: $chr(160) bug - I found the reason :) - 08/06/04 01:00 AM

It's amazing how i learn a new thing everyday laugh Thanks for the lesson! smile

Zyzzy.
Posted By: Sais

Re: $chr(160) bug - I found the reason :) - 08/06/04 12:58 PM

Could someone confirm that the following *doesn't* cause the hang problem:

/say ああ

or equivalently (and to prove it contains a 160 char):

//bset &t 1 130 160 130 160 | say $bvar(&t,1-).text

For those who cannot see/read the Japanese, this is two hiragana characters for the syllable 'a'.

It doesn't appear to hang my system - I'm assuming that is because it is "valid" as an input; or perhaps because it is the second byte of the sequence.

I'm looking for a (valid) example with 160 as the first byte - not found one yet. If anyone knows of an exampple, please post.

(It would appear that the characters in the /say line didn't come out correctly in the HTML...)
Posted By: MiSsInGnO

Re: $chr(160) bug - I found the reason :) - 09/06/04 02:17 PM

Well...

I wrote this little code to look for a bouble-bytes char that would use $chr(160) as it's first byte.
//var %i 0 | while (%i < 256) { bset &t 1 160 %i | echo $bvar(&t,1-).text | inc %i }

All those "combinations" seem not to match double-bytes chars. Most of them show a "middle dot" character followed by some other char. (tested with MS Gothic, jap script).

Reversing the order of bytes (bset &t 1 %i 160) indeed shows much more *real* double-bytes chars!
Posted By: Sais

Re: $chr(160) bug - I found the reason :) - 10/06/04 08:23 PM

I'll have to review my sources of information, then wink

I'm thinking perhaps I misread, and the 0xA0 term was the mask for the start of a set, not the real first byte....erg...I think I know what I mean smile

Thanks for the input, though. It's difficult on a non-CJK system to be confident that your tests are actually working.
© 2022 mIRC Discussion Forums