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!
http://tagline.excite.com/fc/JkJQPTgMT4zs9kJdJZyEls812MUpHY1nianv9qUUcz7zSHdWvvZj1B/
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
