[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dysfunktionale GLibC
- To: Gert Doering <gert@greenie.muc.de>
- Subject: dysfunktionale GLibC
- From: PILCH Hartmut <phm@a2e.de>
- Date: Thu, 7 Oct 1999 10:51:17 +0200 (CEST)
- cc: debate@fitug.de
- Comment: This message comes from the debate mailing list.
- In-Reply-To: <19991006221852.I13613@greenie.muc.de>
- Sender: owner-debate@fitug.de
Gert Doering antwortete
> > Die GNU-C-Bibliothek GlibC arbeitet seit Version 2.1 intern mit UCS-4,
> > d.h. 32 Byte. Da wuerde schon der Krempel reinpassen, den die
> > Unicode-Gegner gerne drinhaetten. Aber es waere Verschwendung und wuerde
> > zumindest dafuer
>
> Die glibc 2.1 ist ein hervorragendes Beispiel, warum ich das nicht mag
> (diese Library ist *so* aufgeblaeht und unhandlich, das passt auf keine
> Hutschnur mehr).
Wegen UCS-4 (speicherfressende Felder aus kaum ausgenutzten
4-Byte-Zeichen) ?
Eine Alternative liegt darin, alles Dateien jedes Systems nach UTF-8 zu
wandeln (z.B. eingehende Mail) und dann in Programmen kaum noch auf die
interne Kodierung zurueckzugreifen. UTF-8 arbeitet mit Zeichen
unterschiedlicher Laenge (1-6 Byte), ist dadurch sehr platzsparend.
Das Unix-System Plan-9 arbeitet schon vor 8 Jahren nur mit UTF-8, und
es schien dadurch eine recht schlanke Struktur zu haben.
Moeglicherweise ist die GlibC auch durch Verwendung aufgeblaehter C-Makros
unhandlich. Zumindest hemmt das sehr, wenn man eigene Module einfuegen
moechte. Makros sind ja in mehrfachem Sinne "dysfunktional", aber sie
bringen gelegentlich 1% Geschwindigkeitsgewinn.
-phm