Re: g_utf8_validate() and NUL characters

["Freddie Unpenstein" <fredderic excite com>]

From: "Maciej Katafiasz" , 10/10/2008 00:38

> Den Wed, 08 Oct 2008 23:47:23 -0400 skrev Havoc Pennington:
>> This is why nul is different from other nonprintable characters: that it
>> breaks a bunch of C code, in practice. Nobody does anything special
>> about the other nonprintables, but people treat nul as a special case
>> all over the place.
> So the stack our app uses can't handle NULs. That means the stack needs
> fixing, not that my files are to be declared undisplayable, *especially*
> if I can't even open and inspect said files in partially-gibberish mode
> to see what exactly the problem is. "The platform does/assumes stupid
> things" is not an excuse, we have a library dedicated to fixing such
> things, it's called glib.

I think you're half-right.  It's not the stack that needs to change, it's UTF-8, at least internally.  The stack will naturally follow.

UTF-8 is a "current specification".  That's all.  It'll no doubt be adjusted or simply superseded at some point.  Outside of Glib, it can be viewed as 100% iron-clad, and Glib should uphold that.  But holding it up 100% internally is a convenience that should not be encouraged; it is dangerous to allow external UTF-8 to get into Glib/GTK unvetted, adds unneccedary baggage to support non-UTF-8, and mere convenience to allow internal strings to be passed out as UTF-8.

So I personally see no reason to uphold strict UTF-8 compliance within Glib/GTK.


Fredderic

---

	Fashion Design Education
	Save on a Fashion Design Education. Click Now!
	Click here for more information