Hi Chris, It seems that wcsnlen() only works for wchar_t types and in Unix-like systems, wchar_t is usually stored in UTF-32 format. Therefore by default, it works and only works with 32-bit UTF-32 strings. And I'm pretty sure it can't be configured to deal with fixed-length 16-bit chars.
Concerning strings with NULL in the middle, the instance I have is in an Sms::Body, encoded in 7-bit. Don't know why where the NULL comes from, but however my BlackBerry device displays the content after the NULL correctly. Due to this I think we should have a check before assigning the value to class member, no matter which encoding it is in. And this has nothing to do with strnlen() and wcsnlen(). Best Regards, Ryan Li Chris Frey wrote: > Hi Ryan, > > That's true that strnlen() won't work with multi byte chars, which is > why I mentioned wcsnlen(). I haven't looked too deeply into that > function though, and I don't know if it needs to have an environment > setup before it will work correctly. > > i.e. does it work with 16bit chars and 32 bit chars? That would be good > to know, before we write our own. > > As for strings that have a null in the middle... there are some fields > in the Blackberry that contain two strings in one, using that technique. > Does the second string make sense as another field that we should be > splitting out? > > Thanks, > - Chris ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
