Auslesen einer Datei N in einem Ordner; C

Computer: Software & Programmierung C/C++
#1

Hallo,
hab schon danach gegoogelt, aber nichts brauchbares gefunden.
Ich würde gerne eine beliebige datei in einem festgelegtem ordner öffnen.
Man findet zwar oft, wie man eine fest vorgeschriebene datei öffnet, aber da ich im programm je nach bedarf auf mehrere datein zugreifen möchte, wäre das ein haufen arbeit.
Also quasi so hab ich mir das vorgestellt:
(verkürzt, ganz grob und pseudocode unter C)

void funktion(int dateinr)
FILE *datei
datei = fopen(„Ordner/dateinr“, „r“)
/* dabei ist „dateinr“ eine nr die ich zuvor in der main eingegeben hab*/
int main()
int nr;
scanf("%d", &nr);
funktion(nr);

danke im vorraus
mfg
Hans

#2

Hi,

eine beliebige Datei oder doch eine Datei mit einem festgelegten Namensschema?

FILE *datei
char datname[300];

sprintf(datname, „Ordner/Daten%03d.txt“, dateinr);
datei=fopen(datname, „r“);

if(datei==NULL){ Fehlerbehandlung, Datei existiert nicht. }

usw.

Das setzt voraus, dass der Ordner namens „Ordner“ unterhalb des aktuellen Arbeitsverzeichnisses Dateien mit den Namen Daten001.txt, Daten037.txt, Daten265.txt etc. enthält.

Gruß Lutz

#3

Hallo allesamt,

eine beliebige Datei oder doch eine Datei mit einem
festgelegten Namensschema?

FILE *datei
char datname[300];
sprintf(datname, „Ordner/Daten%03d.txt“, dateinr);

eine derartige Loesung fuehrt zu den bekannten Schlupflöchern für Viren und Trojanern.

Zunaechst darf man durchaus annehmen, dass ein Pfad laenger als 299 Zeichen lang sein darf. In vielen OS gibt es dafuer auch eine Konstante MAXPATHLEN, fuer Windoofs lese den Artikel

http://msdn.microsoft.com/en-us/library/aa365247.aspx

Zum zweiten sollte dann diese Laenge auch beim Schreiben in den Buffer ueberprueft werden. Dafuer gibt es die Funktion snprintf oder deren Varianten.

s **n** printf(datname,**sizeof(datname)**, "Ordner/Daten%03d.txt",dateinr);

Zum dritten wird die schöne Einheitlichkeit der Dateinamen von 0 bis 999 8 (000…999) zerstört, wenn man dann doch mehr als 999 Dateien benoetigt, also sollte der Formatstring sorgfaeltig gewaehlt werden. Wenn gar keine Zahlen benoetigt werden, sondern nur temporaere Dateien, dann waer vielleicht auch eine Loesung mit den tmpnam Varianten angebracht, siehe dazu

http://www.cplusplus.com/reference/clibrary/cstdio/t…

Im wesentlich war das also eine Mathematiker Loesung, keine Informatiker Loesung :wink:

SCNR …
norsemanna

#4

Ähm,

lass mal zählen:

„Ordner/Daten%03d.txt“

hat 16 feste Zeichen und 3 durch den Integer-Wert, also sollte hier sogar char[20] ausreichen. Da %03d nur 3 als untere Längenschranke angibt, könnte sich da immer noch eine 10 oder 11-stellige Zahl aus einem 32Bit-Integer ergeben. Aber char[300] ist dafür auf jeden Fall ausreichend.

Ja, man sollte auf Buffer-Overflow achten, der aber hier gar nicht möglich ist. Wer zu oft „Wolf“ ruft, wird irgendwann unglaubwürdig.

Genaueres lässt sich natürlich erst sagen, wenn der Fragesteller seine Ausgangslage auf ein realistisches Szenario korrigiert hat.

Gruß Lutz

#5

Howdy,

Ja, man sollte auf Buffer-Overflow achten, der aber hier gar
nicht möglich ist. Wer zu oft „Wolf“ ruft, wird irgendwann
unglaubwürdig.

noch einmal: Programmierung muss auch dann sicher sein, wenn man zum Zeitpunkt des Codens eine andere Situation vorfindet.

Hier findet man vor, dass __derzeit__ zwar nur ein paar handvoll Zeichen verwendet werden. Spaeter fuegt man ein paar weitere Zeichen hinzu und kuemmert sich nicht um den Rest …

Wiederum etwas spaeter fuegt man einen Pfad hinzu, der durch eine Environmentvariable eingelesen wird und schon ist der Pfad zu lang und wir haben das Problem, wohlmerkend: das Problem existiert nur in deiner Loesung, in der von mir vorgeschlagenenen Loesung kann man soviele Zeichen hinzufuegen, wie man will, man erhaelt nie einen Bufferoverflow …

Das Ganze gehört zum „defensiven Programmieren“

http://en.wikipedia.org/wiki/Defensive_programming

und ja, mir ist bekannt, dass das idR Mathematikern nicht interessiert. Ich weiss, wovon ich rede, denn ich finde taeglich - zusaetzlich zu den anderen Programmierfehlern und Ineffizienzen - derartiges in Codemodulen, die unsere Nichtinformatiker fabriziert haben … Man findet es sehr sehr selten in den Codemodulen von (ausgebildeten) Informatikern …

Gruss
norsemanna