On Sun, 2002-04-07 at 07:18, Peter Zelezny wrote:
> That would still require a server-dependant string comparision function.
> I really don't want to put something like this in 50 odd places:
>
> if (serv->breaks_rfc1459_strcmp)
> strcasecmp();
> else
> rfc_cmp();
--- BEGIN CODE SNIPPET ---
/* in xchat.h */
typedef int (*irc_strcasecmp)(const char *, const char *);
typedef int (*irc_strncasecmp)(const char *, const char *, size_t);
struct server {
/* ... */
irc_strcasecmp strcasecmp;
irc_strncasecmp strncasecmp;
};
/* elsewhere */
struct server *serv; /* defined elsewhere */
serv->strcasecmp(/* ... */);
--- END CODE SNIPPET ---
Then you simply put in the str(n)casecmp functions you want to use for
that server into serv->str(n)casecmp. Regular str(n)casecmp can be used
for servers that do that, and you could have a 1459_str(n)casecmp
function for RFC 1459 servers.
> I understand it was a stupid decision for the original rfc to use that weird
> scandinavian case conversion, but it's now set in stone. If you were designing
> a new protocol, of course you'd go with a standard locale strcasecmp, but you
> aren't. You arn't archieving anything positive by going with a non-1459
> compare. Making the irc2 protocol more "clean" might sound nice, but you'll
> just break compatability. Before long, numeric 005 will get so long, it'll
> go over the 512 byte limit.
Who says they have to keep the 512 byte limit? People don't generally
IRC from 300 baud modems these days. Anyway, if they're designing a new
protocol, shouldn't the protocol be _new_? Perhaps it could be a
thoroughly compact binary protocol, for instance.
Regards,
Alex.
--
PGP Public Key: http://aoi.dyndns.org/~alex/pgp-public-key
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s:++ a18 C++(++++)>$ UL+++(++++) P--- L+++>++++ E---- W+(+++) N-
o-- K+ w--- !O M(+) V-- PS+++ PE-- Y+ PGP+(+++) t* 5-- X-- R tv b- DI
D+++ G e h! !r y
------END GEEK CODE BLOCK------
This is a digitally signed message part