| ||||||||||||||||||||||||
![[Date Prev]](/grafix/mhonarc/prev.png)
![[Date Index]](/grafix/mhonarc/up.png)
![[Date Next]](/grafix/mhonarc/next.png)
|
|
|
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||
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/
|
|
|
||||||||||||
|
||||||||||||||
| ||||||||||||||
|
||||||||||||||
|
|
|
||||||||||||