Last Comment Bug 3834 - Locale- nsICollation to add interfaces using nsString
: Locale- nsICollation to add interfaces using nsString
Product: MailNews Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: All All
P3 normal (vote)
: M4
Assigned To: nhottanscp
: Katsuhiko Momoi
Depends on:
  Show dependency treegraph
Reported: 1999-03-16 13:24 PST by nhottanscp
Modified: 2008-07-31 01:22 PDT (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image nhottanscp 1999-03-16 13:24:54 PST
By using nsString instead of byte stream/length pair, we can reduce XPCOM
Comment 1 User image nhottanscp 1999-03-22 17:30:59 PST
Change checked in on 3/19/99.
At this point, my test cases are limited to very simple us-ascii strings. There
is a test code checked in. So I would like someone in IQA to do unit tests.

Currently, there are platform specific limitation.
Win32 - #3867 nsLocale problem
Mac,Unix - #3903,3904 only en_US is supported
Work around for these problem is to pass NULL for nsILocale to force use a
default (en_US) until #3867 is resolved.
Comment 2 User image nhottanscp 1999-03-29 17:50:59 PST
The code has been checked in.
IQA will do tests us-ascii data for Win32.
Comment 3 User image Katsuhiko Momoi 1999-03-31 14:44:59 PST
On US-Windows  95 using Naoki's LocaleSelfTest.exe, I got results found here:


These results are not correct with an initial character like "Z" coming right after "I".
There are many other problems with these results suggesting that ascii-collation
on US-Windows 95 is broken.
Comment 4 User image nhottanscp 1999-03-31 16:19:59 PST
Looks like that unicode version of the API is not fully working under Win95.
I need to use a converter and non unicode API for Win95. Fortunately, the code
has been written for Mac and Unix so I can reuse it and check in by the week
Comment 5 User image nhottanscp 1999-04-01 13:41:59 PST
I checked in the fix for Win95,98.
It should work for us-ascii data except requires to pass NULL as for a locale
until the bug #3867 fix.
Comment 6 User image nhottanscp 1999-04-01 15:04:59 PST
IQA has found platform dependent behavior for case less comparison.
I will investigate the problem but it is not critical for M4 (only significant
for Naoki vs naoki).
Setting to M5.
Comment 7 User image nhottanscp 1999-04-01 21:44:59 PST
I checked in a fix for the case less comparison problem.
Comment 8 User image nhottanscp 1999-04-02 10:02:59 PST
For M4, please test us-ascii data in Win32 (NT4, 95, 98). Create a new bug for
any sort order issue.
Marking bug as resolved fixed.
Comment 9 User image bobj 1999-04-07 14:56:59 PDT
Bookkeeping: Moved from M5 to M4 since its already fixed.
Comment 10 User image Katsuhiko Momoi 1999-04-09 00:33:59 PDT
** Checked with 4/8/99 evening build for Win32 on US Win NT4/98/95 **

To test this, we (marina & momoi) used:

1. the source for the latest LocaleSelfTest.exe for Win32 is at:

2. data files to sort are found here:

   Files: us-ascii_base.txt  (contains the entire ASCII characters)
          us-ascii_sort.txt  (contains various key strings for tests)

As of 4/9/99, there is one error in the us-ascii_base.txt. The corrected
file and the corresponding results will be checked in later today.


The 4 result files are found here:

These results by marina and momoi agree that in all 3 Win OS's, there is
consistency in the results. In earlier version of LocaleSelfTest.exe, we
saw the sorted order even when the sort option was set to
"case insensitive", but this defect is now gone with the latest
version (make files modified last on 4/7/99) of LocaleSelftest.exe.

In the sorted order, lowercase letters preceded uppercase ones in all
the results and this is expected behavior.

Marking the fix verified.

Note You need to log in before you can comment on or make changes to this bug.