mIRC Home    About    Download    Register    News    Help

Print Thread
$chr(160) bug - I found the reason :) #85292 04/06/04 04:18 PM
Joined: Dec 2002
Posts: 12
T
TimeFX Offline OP
Pikka bird
OP Offline
Pikka bird
T
Joined: Dec 2002
Posts: 12
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

Re: $chr(160) bug - I found the reason :) #85293 04/06/04 10:56 PM
Joined: Jun 2004
Posts: 3
A
Aoshi Offline
Self-satisified door
Offline
Self-satisified door
A
Joined: Jun 2004
Posts: 3
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

Re: $chr(160) bug - I found the reason :) #85294 05/06/04 11:52 AM
Joined: Jun 2004
Posts: 5
K
kibou Offline
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
K
Joined: Jun 2004
Posts: 5
160 is the ASCII number for a no break space.

Re: $chr(160) bug - I found the reason :) #85295 05/06/04 05:24 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
quite untrue, chr 160 is not a "defined" key, its different on many fonts and shouldnt be trusted as a reliable 'nbsp'


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: $chr(160) bug - I found the reason :) #85296 05/06/04 06:53 PM
Joined: Oct 2003
Posts: 313
S
Sais Offline
Fjord artisan
Offline
Fjord artisan
S
Joined: Oct 2003
Posts: 313
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.


Sais
Re: $chr(160) bug - I found the reason :) #85297 05/06/04 06:57 PM
Joined: Mar 2004
Posts: 457
D
Danthemandoo Offline
Fjord artisan
Offline
Fjord artisan
D
Joined: Mar 2004
Posts: 457
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.

Re: $chr(160) bug - I found the reason :) #85298 05/06/04 07:04 PM
Joined: Feb 2004
Posts: 714
Z
Zyzzyx26 Offline
Hoopy frood
Offline
Hoopy frood
Z
Joined: Feb 2004
Posts: 714
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.


"All we are saying is give peace a chance" -- John Lennon
Re: $chr(160) bug - I found the reason :) #85299 08/06/04 12:26 AM
Joined: Oct 2003
Posts: 313
S
Sais Offline
Fjord artisan
Offline
Fjord artisan
S
Joined: Oct 2003
Posts: 313
go to alt-o IRC->messages, enable SJIS/JIS conversion

now :

Code:
 //say $chr(160)  


(you need to be connected to a server)


Sais
Re: $chr(160) bug - I found the reason :) #85300 08/06/04 12:34 AM
Joined: Feb 2004
Posts: 714
Z
Zyzzyx26 Offline
Hoopy frood
Offline
Hoopy frood
Z
Joined: Feb 2004
Posts: 714
Oh, i see smile But what's the difference between the $chr(160) and $chr(32)?

Thanks for the help smile

Zyzzyx.


"All we are saying is give peace a chance" -- John Lennon
Re: $chr(160) bug - I found the reason :) #85301 08/06/04 12:48 AM
Joined: Oct 2003
Posts: 313
S
Sais Offline
Fjord artisan
Offline
Fjord artisan
S
Joined: Oct 2003
Posts: 313
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.


Sais
Re: $chr(160) bug - I found the reason :) #85302 08/06/04 01:00 AM
Joined: Feb 2004
Posts: 714
Z
Zyzzyx26 Offline
Hoopy frood
Offline
Hoopy frood
Z
Joined: Feb 2004
Posts: 714
It's amazing how i learn a new thing everyday laugh Thanks for the lesson! smile

Zyzzy.


"All we are saying is give peace a chance" -- John Lennon
Re: $chr(160) bug - I found the reason :) #85303 08/06/04 12:58 PM
Joined: Oct 2003
Posts: 313
S
Sais Offline
Fjord artisan
Offline
Fjord artisan
S
Joined: Oct 2003
Posts: 313
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...)


Sais
Re: $chr(160) bug - I found the reason :) #85304 09/06/04 02:17 PM
Joined: Dec 2002
Posts: 19
M
MiSsInGnO Offline
Pikka bird
Offline
Pikka bird
M
Joined: Dec 2002
Posts: 19
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!

Re: $chr(160) bug - I found the reason :) #85305 10/06/04 08:23 PM
Joined: Oct 2003
Posts: 313
S
Sais Offline
Fjord artisan
Offline
Fjord artisan
S
Joined: Oct 2003
Posts: 313
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.


Sais