75551 - [API] need a case INSENSITIVE way to search an nsAReadableString

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[mjudge]

this is blocking the editor right now, the only way around this for now is to 
copy the string to an nsString and use the nsString methods.  We need a helper 
function that can accept some iterators and return usual compare result for 
ASCII text compares.

Comment 1

[Scott Collins]

case insensitive search, case insensitive compare; this is an encoding issue,
api issue, and related to work I want to do on string `alogorithms', that is,
more functions like |copy_string| that take one or more strings and iterate over
them applying the caller-supplied visitor to each hunk, and testing for completion

Comment 2

[Scott Collins]

It's unlikely I'll have a bug free version for you by tree-closure tonight, but
I'll bust my butt to try to give it to you.  Based on conversations with you and
others on IRC, I'm calling this my most important 0.9 bug.  We should
communicate this fact to drivers to help get it in after the fact if we miss
tonights deadline.

Comment 3

[Scott Collins]

These are the 0.9 bugs that didn't make it, and that I intend to fix in 0.9.1

Comment 4

[Scott Collins]

re-targeting milestones, starting from a clean slate

Comment 5

[Scott Collins]

marking the functionality blockers for immediate attention in mozilla0.9.1

Comment 6

[Scott Collins]

Attachment: adds case-insensitive |FindInReadable| ... trying not to charge callers of the exact match version

Comment 7

[Scott Collins]

and I'm in the midst of testing it

Comment 8

[Simon Fraser [no longer active]]

Looks good. Just one comment:

+class CaseInsensitiveCharComparator
+  {
+    public:
+      PRBool operator()( char lhs, char rhs ) const { return nsCRT::ToUpper(lhs) 
== nsCRT::ToUpper(rhs); }
+  };
 
Will the calls to nsCRT::ToUpper be inlined? If no, this could be a bottleneck.
Can we call toupper directly?

sr=sfraser if you think that's not an issue.

Comment 9

[Johnny Stenback (:jst)]

r=jst

Comment 10

[Scott Collins]

re: sfraser's comments --- I actually _do_ think it's an issue.  Perhaps for
ASCII I should be building a different mechanism.  The |PRUnichar| version is
not |inline|able, since it goes into the i18n code that theorecically does it
right using code around very compressed tables.  The |char| version, though,
could be made to do the right thing.  All these routines are wrong headed
though, because they presume a flat encoding, when no such promise has been
made.  At least they continue to offer the level of functionality people need.

Comment 11

[Scott Collins]

patch checked in

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Any plans for CaseInsensitiveRFindInReadable?