Betrachten wir zunächst folgendes Beispielprogramm:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
printf("sizeof(void*) = %d\n", sizeof(void*));
printf("sizeof(off_t) = %d\n", sizeof(off_t));
FILE *file = fopen("testfile", "w");
if(!file) return -1;
size_t len = 1024*1024*256;
char *buf = malloc(len);
int count = 0;
while(fwrite(buf, 1, len, file) == len) {
count++;
if(count >= 10)
break;
}
printf("count: %d\n", count);
fclose(file);
return 0;
}
Das Programm öffnet eine Datei und schreibt dann 10 mal einen 256MB großen Block. Insgesammt sollte eine 2,5GB große Datei rauskommen. Kompilieren wir das Programm nun im 32bit Modus mit cc -m32 -o test test.c wird die Schleife nicht 10 mal ausgeführt, denn vorher überschreitet die Datei eine Größe von 2GB. Die APIs können auf Grund des 32bit Limits nicht mit größeren Dateien umgehen.
Es gibt jedoch ein Large File Interface für 32bit Anwendungen, damit diese auch mit größeren Dateien umgehen können. Dazu stehen neben den typischen Funktionen, wie z.B. open, fopen, stat, lseek, fseek, ftell, usw., 64bit fähige Funktionen zur Verfügung, deren Name einfach nur um ein 64 erweitert wurde (open64, fopen64, ...). Außerdem gibt es zusätzliche Typen wie off64_t.
Jetzt wäre es etwas unschön, müsste man immer diese 64 bit fähigen Funktionen direkt verwenden, und daher seinen ganzen Code anpassen. Doch definiert man _FILE_OFFSET_BITS=64 stehen unter den alten Namen die 64bit fähigen Funktionen bzw. Typen zur Verfügung. Damit ist off_t nun in 32bit Anwendungen 64bit groß und fopen wird transparent durch fopen64 ersetzt. Wir können also das obere Beispiel einfach mit cc -D_FILE_OFFSET_BITS=64 -o test test.c kompilieren und es verhält sich dann wie sein 64bit Pendant.
Das ganze sollte unter jedem unixoiden Betriebsystem funktionieren. Unter OS X sind die IO-Funktionen allerdings standardmäßig schon im 64bit-Modus und die *64-Funktionen existieren dort nicht.
Siehe auch: lf64(5)
Kommentare
Rudi | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Damit wird Nedit durch XNedit ersetzt.
Danke!
Olaf | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Anti-Aliasing hängt von der Schriftart ab. Mit einem bitmap font sollte die Schrift klassisch wie in nedit aussehen.
Einfach unter Preferences -> Default Settings -> Text Fonts nach einer passenden Schriftart suchen.
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Mettigel | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ich hatte gedacht, dass der GX-415 im s920 deutlich mehr Dampf hat als der Raspi4.
Mein Thinclient verbraucht mit 16 GB RAM ~11 W idle, das ist das Dreifache vom RP4. Das muss man dem kleinen echt lassen... Sparsam ist er.
Olaf | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ergebnisse von der Ultra 80 wären natürlich interessant, insbesondere im Vergleich mit dem rpi1.
kosta | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
ich hätt hier zugriff auf Ultra-80 4CPU 4GB 2x Elite3D.
RO | Artikel: Benutzt bitte nur noch Unicode!
Sehe ich genauso.