View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003271 | unreal | ircd | public | 2007-04-12 04:55 | 2007-04-19 03:05 |
| Reporter | Ldunda | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.3 | ||||
| Summary | 0003271: "/mode #channel +b H e l p !*@* Ascii character use between vacuum ban is throwed. | ||||
| Description | "/mode #channel +b H(Alt+255)e(Alt+255)l(Alt+255)p(Alt+255) When we use this , In this shape Ban is throwing. *** Ldunda sets mode: +b H e l p !*@* /mode #channel +b H e l p When we use this , This is getting out ; *** Ldunda sets mode: +b H!*@* | ||||
| 3rd party modules | |||||
|
|
Not really a bug. IRC protocol is that only an ASCII space (char 32, 0x20) is a parameter seperator (and comma is generally used as a list seperator within a single parameter). Anything else, even if it looks like a space, is not a seperator, and legal to use as part of a single parameter with the exceptions of char 0 which is of course C's string terminator and linefeeds (char 10 and 13) which are command terminators. Indeed, you can have quite some fun with that, using nonbreaking spaces etc. in places where you aren't normally able to use spaces (spamfilter reason for example could be made using nonbreaking spaces even though _ works fine). I should also point out: any ASCII character value above 127 generally can't be gaurunteed standard. At this point, the user's code page comes in to effect. Nonbreaking space on your system could be a different code on another. |
