[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [LOCALE] UTF-8 er noget værre slam



Jacob Sparre Andersen <sslug@sslug> writes:

> Ole Laursen skrev:
>> Jacob Sparre Andersen skrev:
>
>> > Er det nok at justere definitionen af »char« i GCC til
>> > at være på 32 bit og oversætte kernen for at køre med en
>> > 32 bit fast-længde tegnkodning? Eller er det ikke?
>> 
>> Selv hvis POSIX skulle tillade det, kan man simpelthen
>> ikke - der er ufatteligt mange programmer der er bygget op
>> om at char er en byte.
>
> Ufatteligt mange defekte programmer med andre ord.

Nej, de var ikke defekte da de blev skrevet. Og de er heller ikke
defekte nu. Hvis der er noget der er defekt, så er det C. Omvendt kan
man dårligt klandre det for at være defekt i betragtning af at det
blev udarbejdet i en verden der ser noget anderledes ud end verden gør
i dag.

> Jeg må da indrømme at jeg er opmærksom på at ganske mange
> (næsten alle?) C-programmører antager at en "char" er på 8
> bit.  Men skal vi lade være med at rette i POSIX bare fordi
> folk antager ting der ikke er understøttet af nogle
> standarder.

Ja. Bare fordi man ikke skriver noget i en standard, kan det godt være
blive til praksis alligevel.

> Bortset fra at det vil smadre alle de defekte programmer (og
> der er mange af dem), så tiltaler løsningen med at POSIX
> definerer "char" til at fylde 32 bit mig altså meget.  

Ved du hvad, jeg er rimeligt ligeglad med hvad der tiltaler dig. Jeg
er mere interesseret i at jeg kan bruge alt det software der er blevet
skrevet de sidste 30 år. Samt alt det hardware der er købt inden for
de sidste 10 år og stadig kører fint (f.eks. Solaris-serverne på
universitetet).

Jeg har programmeret med UTF-8-strenge i mange år efterhånden, og hvis
man bare benytter et rutinebibliotek, er der ikke noget problem. Så
lad dog være med at forsøge at standse en udvikling du alligevel ikke
kan standse, bare fordi du ikke synes det er den teoretisk pæneste.

Der er altså også teoretiske ulemper ved UCS-4. Til ASCII-tekst bruges
fire gange så meget plads, og man løber ind i endianproblemer. Alene
sidstnævnte det er værre end at skulle håndtere variable tegnlængder,
forestil dig hvordan en tidligere velfungerende tekstprotokol som HTTP
kan gå helt kold hvis man ikke får testet mellem maskiner med
forskellig endianess.

-- 
Ole Laursen
http://www.cs.aau.dk/~olau/


 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 20:55 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *