🚀 go-pugleaf

Boudewijn W. Ch. Visser <visser@ph.tn.tudelft.nl> wrote:
>nomail@pe1chl.demon.nl (Rob Janssen) writes:

>>dat je voor de size van de file een variabele gebruikt met een grotere
>>lengte dan de woordbreedte van de machine.

>>Daar heeft men bij Linux dus niet op gelet.
>>(je kent dat wel...  "2GB files are large enough for everyone")

>>Extra complicatie is dat men Linux een API wil geven die lijkt op die van
>>Unix, en in Unix is het zo dat de filesize een "long int" is.  De lengte 
>>van een "long int" is zowel op 16 als op 32 bits machines 32 bits, en
>>omdat hij ook nog "signed" is kun je maar 31 bits gebruiken.

>Die file API zit nogal diep in Unix en allerlei applicaties ingebakken.
>Dus -zo- kortzichtig is het nou ook weer niet van Linux. Tot Solaris 7
>(64 bit) heb je hetzelfde probleem bij Sun, bijvoorbeeld.

>Hele massa's programma's zouden allemaal problemen hebben gehad
>als fseek opeens niet meer 'gewoon' werkte met een long int.

>Wat dan, GCC extensie ? Extra veld erbij kludgen ? 
>Of een extra 'large file' API ?
>Ik geloof dat dat laatste nu de keus is geworden.

>De houding is eerder  : If you need more than 2GB files, get a real
>machine.
>(Alpha, UltraSparc).

Grappig he, als Microsoft zo iets zou doen om compatability redenen dan
is dat allemaal waardeloos, en als ze een "large memory" truuk uithalen
dan is dat onhandig.  Maar als in Linux een dergelijke keus gemaakt wordt
dan is dat verklaarbaar en is de compatabiliteit belangrijk en had je
maar een andere machine moeten kopen.  (wat nergens op slaat, want hoe
groot je files zijn zegt NIKS over hoe breed je registers moeten zijn
of hoe snel je processor)

Rob
-- 
+----------------------------------+--------------------------------------+
| Rob Janssen     pe1chl@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet:     rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+