fopen & Segmentation Fault
-
Hi,
die Fehlerüberprüfung mache ich für beide Files, wenn auch in diesem Falle nicht in der gleichen Zeile, in der die Datei geöffnet wird. Mir ist durchaus klar, daß ich überprüfen muß, ob die Datei sauber geöffnet wurde... bin zwar kein alter Hase, aber auch kein Neuling in C - habe einfach nur lange nix mehr in C geschrieben
EDIT: ganz vergessen... das File wird auch angelegt, als Rückgabewert erhalte ich einen Wert != NULL, das funktioniert also sauber, aber die nächste Codezeile wird eben nicht mehr ausgeführt
-
Das wird sich so nicht beantworten lassen.
-
Daniel, kein t? Check das mal. rwa und wt+ gibt es für meine Begriffe. Portability ANSI und POSIX sagt mein Helpfile.
-
Schick doch mal alles von fopen bis zu der Stelle wo der Fehler auftritt und ruhig noch 2 oder 3 Zeilen dazu
-
Bitsy schrieb:
Check das mal. rwa und wt+ gibt es für meine Begriffe. Portability ANSI und POSIX sagt mein Helpfile.
Ich lese mal vor (ich habe hier die Norm nur als Textdatei, darum wird alles etwas seltsam aussehen):
1 #include <stdio.h>
FILE *fopen(const char * restrict filename, const char * restrict mode);
[...]
3 The argument mode points to a string. If the string is
one of the following, the file is open in the indicated mode. Otherwise, the behavior is undefined.228)r open text file for reading
w truncate to zero length or create text file for writing
a append; open or create text file for writing at end-of-file
rb open binary file for reading
wb truncate to zero length or create binary file for writing
ab append; open or create binary file for writing at end-of-file
r+ open text file for update (reading and writing)
w+ truncate to zero length or create text file for update
a+ append; open or create text file for update, writing at end-of-file
r+b or rb+ open binary file for update (reading and writing)
w+b or wb+ truncate to zero length or create binary file for update
a+b or ab+ append; open or create binary file for update, writing at end-of-fileSiehe 7.19.5.3 The fopen function aus ISO/IEC 9899:1999
POSIX (susv3 gibt es für Nullum im Internet einsehbar) gibt auch kein t an.
-
Daniel E. schrieb:
POSIX (susv3 gibt es für Nullum im Internet einsehbar) gibt auch kein t an.
C/C++ GE-PACKT ebenfalls nicht. Also nicht im C99 Standard enthalten.
-
THE_FreaK schrieb:
C/C++ GE-PACKT ebenfalls nicht. Also nicht im C99 Standard enthalten.
siehe
Daniel E.s Quote, bzw. die Quellen Angabe
Daniel E. schrieb:
ISO/IEC 9899:1999
das ist der C 99 Standard
-
als kleine anmerkung:
ich kenne keine implementation die t nicht schluckt (auch wenn es ignoriert wird)
-
Hi,
na, was die Modes angehen, schaue ich für sowas meist direkt in die Beschreibung der verwendeten Lib rein, hier die libc6: http://www.gnu.org/manual/glibc-2.2.5/html_mono/libc.html
BTW, ist es unter Linux nicht ohnehin egal, ob ich "b" oder sonstwas angebe?! Linux nimmt doch ohnehin alles als Binärfile.
Naja, wie ich vermutet habe, das Problem liegt an anderer Stelle und hat letzlich nichts mit dem Öffnen der Datei zu tun - nur dort kam eben die Fehlermeldung. Das Problem ist mittlerweile behoben.
Danke für den Support
-
@jogix
Ich glaub da liegst du falsch.
Die b und t Moden unterschiden sich in der Interpretation des line end Symbols. Und das dürfte auch in Linux so sein.
-
Unter Linux (UNIX allgemein?) wird nicht zwischen bin-Datei und text-Datei unterschieden. Das 'b' wurde nur eingeführt, weil es eben Systeme (DOS, Windows) gibt, die diese Unterscheidung erfordern.
-
Nochmal: POSIX und ISO-C kennen kein t, und POSIX macht das b-Flag tatsächlich überflüssig. Also kannst Du unter Linux das b-Flag an- und abgeben, wie Du lustig bist. Zur Verdeutlichgung, was man da eigentlich macht, ist es trotzdem ganz hilfreich.
-
wie bekomme ich dann die lineend bei fgets hin wenn ich nicht im Textmode öffnen kann liest er doch die vorgegebene Anzahl Zeichen?
-
Ich verstehe zwar deinen Satz nicht so wirklich, aber fgets liest so lange Zeichen in den angegeben Puffer, bis (a) 'angegeben viele' Zeichen gelesen wurden, (b) ein '\n'[¹] auftritt oder (c) das Dateiende erreicht wird ((d) ein Lesefehler (-> ferror)).
[¹]: '\n' ist unter Unix das Zeilenende. Kombinationen aus 2 Zeichen, wie in anderen Betriebssystemen üblich ist, braucht es nicht.
-
Du gibst die Antwort selbst
im text mode möchte ich das a,b,c,d beachted wird
im binaer mode möchte ich das a,c,d beachted wirdAlso, in text mode, carriage return–linefeed combinations are translated into single linefeeds on input, and linefeed characters are translated to carriage return–linefeed combinations on output
Open in binary (untranslated) mode; translations involving carriage-return and linefeed characters are suppressed.
-
PAD schrieb:
Du gibst die Antwort selbst
Die Antwort auf was?
im text mode möchte ich das a,b,c,d beachted wird
im binaer mode möchte ich das a,c,d beachted wirda,b,c,d?
untranslated
Es gibt keine verschiedenen Übersetzungsmodi in Unix. Alles Text.
-
:p Ok angekommen, durch die Unix Konvention Textzeilen nur mit \n abzuschließen sind die Translation nicht nötig, und somit
die Modi auch nicht. :pa,b,c,d waren die von die vergebenen Unterpunkte in deiem Posting von 14:01
-
PAD schrieb:
a,b,c,d waren die von die vergebenen Unterpunkte in deiem Posting von 14:01
Oh Gott, da habe ich ja mal wieder richtig mitgedacht :).