🚀 go-pugleaf

In article <4he9gg$m9l@pentagon.io.com> jamshid@io.com (Jamshid Afshar)
writes:

|> Is there an easy way to test if a multibyte string contains only
|> singlebyte characters and thus can be passed to a function expecting a
|> "regular" char*?  Is "if (strlen(mbs)==mblen(mbs))" a valid test and
|> is there anything better?

"if ( strlen( mbs ) == mblen( mbs ) )" is definitly wrong.  mblen
returns the number of byte in a (single) multi-byte character, not in
the string.  About the only way I can think of doing this is by brute
force, with a loop:

	bool				isMultibyte = false ;
	while ( ! isMultibyte && *mbs != '\0' )
	{
		int					n = mblen( mbs , -1 ) ;
		isMultibyte = (n > 1) ;
		mbs += n ;
	}

|> Why aren't there wchar_t versions of functions like atoi() strtod()?
|> Do they just have to be converted to multibyte strings, and do atoi(),
|> etc. work with multibyte strings?

According to the standard: ``In other that the "C" locale, additional
implementation-defined subject sequence forms may be accepted.''  In
plain English: the implementor is allowed to support them, but not
required to.

|> Btw, VC++4's docs say that if mbstowcs()'s wchar_t* destination
|> argument is NULL then the function doesn't do a conversion of the
|> multibyte string; it just returns the size needed to store the
|> multibyte string.  Accepting a NULL first argument is not required by
|> Standard C, is it?

No mention of it in my copy of the standard.

|> Also, the VC++4 docs seem to indicate fputws(), a
|> wchar_t version of fputs(), is "ANSI" compatible.  Standard C doesn't
|> actually specify any wide-character i/o functions, does it?

There not in the index, anyway.

The actual support for internationalization in C is very weak.  The only
justification for this is that when the C standard was adopted, such
support was totally lacking in all other languages; C was a definite
inovater in this respect.

I believe that there are a number of additional functions which have
been proposed for C9x.  Maybe one of the other readers can fill us in.
You might also want to check out http://www.dmk.com/dmk/index.html,
which is where all of the proposals are archived.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone