From: D. Starner (shalesller@writeme.com)
Date: Sat Dec 11 2004 - 18:47:58 CST
"Marcin 'Qrczak' Kowalczyk" writes:
> But demanding that each program which searches strings checks for
> combining classes is I'm afraid too much.
How is it any different from a case-insenstive search?
> >> Does "\n" followed by a combining code point start a new line?
> >
> > The Standard says no, that's a defective combining sequence.
>
> Is there *any* program which behaves this way?
I misstated that; it's a new line followed by a defective combining sequence.
> It doesn't matter that accented backslashes don't occur practice. I do
> care for unambiguous, consistent and simple rules.
So do I; and the only unambiguous, consistent and simple rule that won't
give users hell is that "ba" never matches "bä". Any programs for end-users
must follow that rule.
> My current implementation doesn't support filenames which can't be
> encoded in the current default encoding.
The right thing to do, IMO, would be to support filenames as byte strings,
and let the programmer convert them back and forth between character strings,
knowing that it won't roundtrip.
> If the
> program assumed that an accented slash is not a directory separator,
> I expect possible security holes (the program thinks that a string
> doesn't include slashes, but from the OS point of view it does).
If the program assumes that an accented slash is not a directory separator,
then it's wrong. Any way you go is going to require sensitivity.
> > The rules you are offering are only simple and unambiguous to the
> > programmer; they appear completely random to the end user.
>
> And yours are the opposite :-)
Programmers get to spend a lot of time dealing with the "random"
requirements of users, not the other way around.
-- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
This archive was generated by hypermail 2.1.5 : Sat Dec 11 2004 - 18:48:39 CST