Well, I guess I have some work to do since I have been using StrN* functions
to do most byte array operations. I really hope that this gets documented
somehow..
It should have at least mentioned that "for those who expect unix style
strncmp,
use MemCmp since StrN* functions are now i18ned." or something like that.
Anyhow, Thanks for clearing that up. =)
-Ji
"Ben Combee" <[EMAIL PROTECTED]> wrote in message
news:42970@palm-dev-forum...
>
> "Stringer" <[EMAIL PROTECTED]> wrote in message
> news:42965@palm-dev-forum...
> >
> > >Subject: Re: StrNCompare & PalmOS4
> > >From: [EMAIL PROTECTED]
> > >Date: Tue, 20 Mar 2001 19:02:02 -0800
> > >
> > >This is the expected behavior. The function accepts "strings" as
> > > parameters. A "string" is a sequence of characters terminated by a
NULL.
> > >
> > >-- Keith
> >
> > BIG BUG!!!!
> >
> > This is a very significant violation from the way strncmp() works.
> >
> > The benefit of the 'N' is that you don't need null terminated strings.
>
> But StrNCompare != strncmp.
>
> It looks like the old StrNCompare became StrCompareAscii and the standard
> StrNCompare is now a wrapper around the internationalized TxtCompare.
>
> The problem is probably due to the StrNCompare code setting the s1Len and
> s2Len parameters to TxtCompare based on an expression like "min(len,
> StrLen(s))", where they really should have created a new routine like
> StrLenAtMost(s, len) which would stop after len characters.
>
> However, since StrNCompare was never specced as working for nonstrings,
this
> isn't a formal bug, just a conceptual one.
>
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
