On Wed, Apr 22, 2009 at 10:53:32AM +0800, Ryan Li wrote: > 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.
ahh yes, I forgot about that... thanks for reminding me. > 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(). I agree that we need to do something about those NULLs. I've applied your patch after all, with minor changes. :-) If you have any info on what those NULLs mean, please let us know. If you want to start working on the builder side of things, it would probably be very useful to know how the Blackberry responds if you send back a null-stripped string. Does it barf? Does it truncate? This might shed some light on what is really going on. Maybe there is a SMS body size limit that the Blackberry is working around. 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
