Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Programming / CodeWarrior / January 2006



Tip: Looking for answers? Try searching our database.

correct behaviour of mbstowcs function

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Hartwig Wiesmann - 05 Jan 2006 22:40 GMT
Hi!

It seems to be that the MSL lib implements the mbstowcs function
differently from Apple's implementation in case the first pointer is NULL.
Apple's implementation seems to return the length of the "in"-string
while MSL always returns 0. When looking at Apple's man pages even
(size_t) -1 should be returned.

Now, what is the right functionality?

Hartwig

PS: man pages from Apple to mbstowc

     #include <stdlib.h>

     size_t
     mbstowcs(wchar_t * restrict wcstring, const char * restrict mbstring,
         size_t nwchars);

     #include <xlocale.h>

     size_t
     mbstowcs_l(wchar_t * restrict wcstring, const char * restrict
mbstring,
         size_t nwchars, locale_t loc);

DESCRIPTION
     The mbstowcs() function converts a multibyte character string mbstring
     beginning in the initial conversion state into a wide character string
     wcstring.  No more than nwchars wide characters are stored.  A
terminat-terminating
     ing null wide character is appended if there is room.

     While the mbstowcs() function uses the current locale, the
mbstowcs_l()
     function may be passed a locale directly. See xlocale(3) for more
infor-information.
     mation.

RETURN VALUES
     The mbstowcs() function returns the number of wide characters
converted,
     not counting any terminating null wide character, or -1 if an invalid
     multibyte character was encountered.

ERRORS
     The mbstowcs() function will fail if:

     [EILSEQ]           An invalid multibyte sequence was detected.

     [EINVAL]           The conversion state is invalid.
Alwyn - 06 Jan 2006 02:27 GMT
> It seems to be that the MSL lib implements the mbstowcs function
> differently from Apple's implementation in case the first pointer is NULL.
> Apple's implementation seems to return the length of the "in"-string
> while MSL always returns 0. When looking at Apple's man pages even
> (size_t) -1 should be returned.

Where does it say that?

> Now, what is the right functionality?

I haven't got the C99 specification to hand, but this is the relevant
part of the Single Unix definition for the function:

> RETURN VALUE
> If an invalid character is encountered, mbstowcs() returns (size_t)-1 and may
> set errno to indicate the error. Otherwise, mbstowcs() returns the number of
> the array elements modified (or required if pwcs is null), not including a
> terminating 0 code, if any. The array will not be zero-terminated if the
> value returned is n.

<http://www.opengroup.org/onlinepubs/007908799/xsh/mbstowcs.html>

Note the words in brackets: 'or required if pwcs is null'.

Alwyn
Hartwig Wiesmann - 06 Jan 2006 17:39 GMT
Hi Alwyn,

Apple says:
The mbstowcs() function returns the number of wide characters converted,
not counting any terminating null wide character, or -1 if an invalid
  multibyte character was encountered.

Sorry, misread. Actually zero should be returned as no characters are
converted when the wchar* pointer is NULL.
Your definition would return the length of the byte character sequence.

MSL always returns 0 when a NULL pointer is passed to mbstowcs.

Hartwig

>>It seems to be that the MSL lib implements the mbstowcs function
>>differently from Apple's implementation in case the first pointer is NULL.
[quoted text clipped - 21 lines]
>
> Alwyn
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.