Re: [Libcdio-devel] Iconv usage and string handling

[Peter Creath]

Well, that's just the point.  The <string.h> functions aren't
unicode-aware -- do you know what their behavior will be for non-ASCII
UTF-8?  If not, you shouldn't use them for UTF-8 strings.

Creating your own type forces you to explicitly cast your non-ASCII
character to an ASCII character when you're assuming that an
ASCII-only function will do the right thing with non-ASCII data.  And
the compiler barks at you if you "accidentally" pass a non-ASCII
string to a routine that expects an ASCII string.

You can explicitly override it, but it doesn't fail silently.  Silent
failure causes many many bugs.

The way libXml2 is doing it is actually the right way.  If it turns
out that strcpy breaks on non-ASCII data, your wrapper can do the
right thing.

Is UTF-8 guaranteed not to have any internal null bytes?

    -P


On 4/25/06, Burkhard Plaum <address@hidden> wrote:
> Hi,
>
> Peter Creath wrote:
> > Is there some preferred type for UTF-8 bytes?  You'd probably want a
> > specific data type so that they don't just look like char*'s.  (E.g.
> > typedef char utf8)  Then you get a little bit of compiler assistance.
>
> In which way will the compiler assist?
> Adding a typedef is easy but I would like things to be as simple as
> possible.
>
> > Is there already a standard type to use?
>
> I would prefer plain "char" with the advantage, that it will be
> compatible with all the string.h functions.
>
> The worst example is libxml2, which defines it's own xmlChar to
> *unsigned* char with the effect that gcc4 will complain about
> signed/unsigned incompatibility whenever a xmlChar* is passed to
> one of the <string.h> functions. To make things worse, they
> "fixed" this by wrapping all the str*() functions too :)
>
> Burkhard
>