Hi Roger,
>Palm OS claims to provide equivalents for the normal string handling
>functions, such as strncmp(), which they advise us to use. If they use
>a similar naming convention for a function, such a StrNCompare(),
>then they should produce an equivalent function.
It is confusing that the String Mgr names are similar to routines
from the standard C library, but the behavior is different. A little
background might be useful here.
From the dawn of time, at least some of the String Mgr routines
differed from their strXXX counterparts because they would re-map
character codes in an attempt to provide better support for the full
8-bit Latin character encoding. For example, StrCompare did a
case-sensitive comparison of re-mapped character codes such that
high-ASCII (e.g. accented) characters sorted in sequence with
low-ASCII characters. This differs from strcmp, which does a simple
byte value comparison of two strings.
When I was working on changes to the OS for Japanese in 3.1, this
issue was discussed at much length. I could have added a parallel set
of string routines that worked properly for Japanese (Shift-JIS),
while leaving the String Mgr versions around that only worked
properly for Latin. The alternative was to modify the String Mgr
routines to always try to do the right thing with text, based on the
device's character encoding.
The three main concerns with creating a parallel set of routines were
(a) it would create a broader API, which was opposite the Palm
philosophy, (b) it would create a confusing situation where there
were Palm OS routines with identical parameters and similar names but
slightly different behavior, and (c) it would reduce the number of
applications that worked properly with Japanese, since all existing
apps would have to be modified to use the new APIs when processing
text, which was the common case I was trying to optimize.
Of course, point (b) also applies to the path taken, in that the
String Mgr routines now diverge even more from the standard C library
routines which have identical parameters and similar names, so we
were kind of screwed either way. Not only that, but some of the
routines needed extra parameters for dealing with multi-byte
encodings such as Shift-JIS (e.g. TxtCompare), so we still wound up
with the String Mgr vs. Text Mgr APIs, which is a bummer.
The real deciding point for me was that the String Mgr routines had
already diverged for equivalency with the standard C library
routines, so it felt more correct to continue down that path and make
them work properly with Shift-JIS as well.
Now, all of this doesn't have a lot to do with why some of the String
Mgr routines now require properly null-terminated strings. The short
answer is that I ran out of time before dealing with all of my
do-later notes, one of which was to remove the need for calculating
string lengths in StrNCompare (and other StrNxxx routines). Failing
that, using an StrNLen routine as Ben Combee suggested would have
been better (and then only if the character encoding wasn't
single-byte).
So what to do, since the 4.0 ROMs are frozen? I could easily create a
small StrGlueNCompare routine that avoids the problem, if that would
be helpful. Also note that in 4.0 there are StrCompareAscii and
StrNCompareAscii routines, which behave like the strcmp and strncmp
routines.
>If they want to create a function which acts differently, then
>either; They should use a different naming scheme, such as
> StrCompareLimited()
>or; Explicitly document where this function differs
I agree that the documentation should be explicit about this, and
will try to ensure that that's the case.
>Can Palm Inc, comment on when StrNCompare() started requiring
>null terminated strings. Has this always been the case or did it start
>with OS 4.0?
Shift-JIS (Japanese) 3.1 or later, and Latin (EFIGS) 4.0 or later.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
