2010-09-05 18 views
8

Wenn eine Datei geöffnet wird, um den folgenden Befehl:Öffnen einer Datei in 'a +' Modus

FILE *f1=fopen("test.dat","a+"); 

Der Mann Seite lautet:

a +

Öffnen zum Lesen und Anhängen (Schreiben am Ende der Datei). Die Datei wird erstellt, wenn sie nicht existiert. Die anfängliche Dateiposition zum Lesen befindet sich am Anfang der Datei, aber die Ausgabe wird immer an das Ende der Datei angehängt ( ).

So hat f1 haben 2 separaten Offset-Zeiger, ein für gelesene & andere zum Schreiben?

Antwort

18

Nr

Es gibt nur einen Zeiger, der zunächst am Anfang der Datei ist aber wenn eine Schreiboperation versucht wird, es bis zum Ende der Datei verschoben wird. Sie können sie unter Verwendung von fseek oder rewind an einer beliebigen Stelle in der Datei zum Lesen neu positionieren, aber durch Schreibvorgänge wird sie wieder an das Ende der Datei verschoben.

+0

Es kann auch nützlich sein zu wissen, dass dies in der Regel in Bezug auf 'open' mit dem O_APPEND-Flag auf POSIX-Systemen implementiert ist: http://pubs.opengroup.org/onlinepubs/7908799/xsh/open.html –

+0

In Fall fseek wird nicht vor dem Lesen aufgerufen, viele Leerzeichen werden im folgenden Code gedruckt. Ich habe erwartet, dass nichts auf dem Bildschirm gedruckt wird. Aber warum sollten Leerzeichen gedruckt werden? Das bedeutet, EOF wurde nicht korrekt gefunden. Wenn ich fseek unten auskommentiere, werden Daten korrekt auf dem Bildschirm gedruckt. 'int main() { DATEI * fp1; Zeichen ch; fp1 = fopen ("m.txt", "a +"); fputs ("Daten angehängt", fp1); // fseek (fp1,0, SEEK_SET); while ((ch = getc (fp1))! = EOF) { putc (ch, stdout); } fclose (fp1); Rückgabe 0; } ' –

4

Nein, es hat nur einen Zeiger.

3

Sie können nie Mischung Lese- und Schreiboperationen auf einem FILE ohne fseek dazwischen zu rufen. Bei einigen Implementierungen funktioniert es zwar wie gewünscht, aber ein davon abhängiges Programm hat ein undefiniertes Verhalten. Somit ist die Frage nach 2 Positionen bedeutungslos.

+0

Wahr. Wenn Sie jedoch jemals die C-Implementierung eines Betriebssystems sehen, die die POSIX-Dateioperationen unterstützt und wo die stdio FILE-Operationen nichts anderes sind als eine dünne Pufferschicht über den POSIX-Dateien (die in diesem Fall ein definiertes Verhalten haben), * bitte * Melden Sie es als einen Fehler gegen dieses Betriebssystem. –

+0

@DairaHopwood: Ich bin verwirrt über das, was du sagen willst. Das Problem des Mischens von Lesen und Schreiben auf stdio ohne eine dazwischenliegende Suche ist nur ein Problem der Pufferung. Es hat nichts mit den zugrunde liegenden Operationen auf Dateideskriptoren zu tun. –

+0

Ich meine, dass ich einen stdio-Implementierungsbuggy betrachte, wenn sein undefiniertes Verhalten in diesem Fall nichts anderes bewirkt, als zu ändern, wo, wenn überhaupt, gepufferte Daten geschrieben werden. Das heißt, die Spezifikation hätte sein sollen, dass die resultierenden Dateiinhalte implementierungsdefiniert sind und nicht wirklich undefiniertes Verhalten. Andernfalls werden Sie feststellen, dass eine Menge Programme ausnutzbare Sicherheitslücken aufweisen. –