Probleme beim Auslesen einer Datei

hartmut1164

Tachyon schrieb:

hartmut1164 schrieb:

In diesen Falle tut man gut daran das Programm zu schnell und brutal als moeglich zu beenden.

Aber nicht, ohne vorher erfolgreich angeforderte Ressourcen wieder freizugeben.
Wenn Du ein OS hast (vielleicht gibt es auch kein OS), welches einem nicht hinterher räumt, bekommt man sonst recht schnell Probleme. Und je nach Ressource kann es auch sein, dass selbst das OS nichts machen kann.

Es gehoert seit dem IBM/360 zu grundlegenden Aufgaben eines OS die Allocierung von Resourcen durch Prozesse zu steuern, sich diese Resourcen "zu merken" und diese ggf. wieder freizugeben.

Das mag bei der Kernel-Prg. anders sein, aber das ist eher "Randbereich - wenn auch ein extrem wichtiger.

Tachyon schrieb:

Und ob "was ziemlich Übles" passiert, wenn kein Speicher mehr zur Verfügung steht, hängt stark vom Programm ab. Erstmal schlagen einfach Anforderungen fehl. Das ist so erstmal kein Grund für einen abort.

Ich saehe nur zwei Szenarien, wo ich das nicht machen wuerde:

Bei extrem beschraeckten Resourcen (z. B. im embedded Bereich)
Bei sehr grossen angeforderten Datenmengen

Selbst bei heutigen Feld-Wald-und-Wiesen-Rechnern mit nahezu unbegrenzten Resourcen im Arbeitsspeicher von 100/1000en von MB erscheint mit Szenario 2) in den meisten Faellen wirklich unwahrscheinlich (gibt auch Ausnahmen, aber das sind Ausnahmen).

Tachyon schrieb:

SIGKILL gibt es gar nicht. Es gibt höchstens SIGTERM.

Steht im Posix-std.; ist bei Linux Signal 9

Tachyon schrieb:

Einen Heap gibts in C btw. nicht.

hartmut1164 schrieb:

Acht und wo stehen in beiden Beipielen meine 100'000 chars?

In 'nem Speicher mit Allocated Storage Duration. Heaps und Stacks gibt es im C-Standard nicht wirklich, weil dort ziemlich konkrete Datenmodelle hinterstehen.[/quote]

Das ergibt sich aus der praktischen Implementation als sequenzielle Abarbeitung der localen Variablen (und Uebergabeattribute) und der dynamischen Verwaltung des z.B. ueber malloc allocierten Speichers. Ich will nicht bezweifeln, dass man das auch anders implementieren kann (heap/Stack), wuesste aber nicht wie.

Tachyon

hartmut1164 schrieb:

Es gehoert seit dem IBM/360 zu grundlegenden Aufgaben eines OS die Allocierung von Resourcen durch Prozesse zu steuern, sich diese Resourcen "zu merken" und diese ggf. wieder freizugeben.

Was ist mit µC, DSPs etc.? Die haben i.d.R. kein OS, das Dir hinterher räumt. Solche Plattformen werden recht oft benutzt und sind weder ein Randbereich noch sonderlich exotisch.
Selbst unter Windows gibt es einige Ressourcen, die nicht wieder freigegeben werden, wenn der zugehörige Prozess stirbt. Einige GDC-Handles z.B.

hartmut1164 schrieb:

Steht im Posix-std.; ist bei Linux Signal 9

Und was hat Posix mit ANSI-C zu tun?

hartmut1164 schrieb:

Ich will nicht bezweifeln, dass man das auch anders implementieren kann (heap/Stack), wuesste aber nicht wie.

Das glaube ich Dir sofort.

Tachyon schrieb:

Selbst unter Windows gibt es einige Ressourcen, die nicht wieder freigegeben werden, wenn der zugehörige Prozess stirbt. Einige GDC-Handles z.B.

meinste GDI-handles? das war mal zur zeit der 16-bit windosen, win98, win-me und so. die nt-abkömmlinge räumen alles sauber wieder weg.

Tachyon

+fricky schrieb:

Tachyon schrieb:

Selbst unter Windows gibt es einige Ressourcen, die nicht wieder freigegeben werden, wenn der zugehörige Prozess stirbt. Einige GDC-Handles z.B.

meinste GDI-handles? das war mal zur zeit der 16-bit windosen, win98, win-me und so. die nt-abkömmlinge räumen alles sauber wieder weg.

Ne, ich meine eher sowas wie Icon-Handles. Da steht sogar explizit dabei, dass die nicht wieder weggeräumt werden.

Tachyon schrieb:

Ne, ich meine eher sowas wie Icon-Handles. Da steht sogar explizit dabei, dass die nicht wieder weggeräumt werden.

kann ich mir nicht vorstellen, haste 'nen link?

Tachyon

+fricky schrieb:

Tachyon schrieb:

Ne, ich meine eher sowas wie Icon-Handles. Da steht sogar explizit dabei, dass die nicht wieder weggeräumt werden.

kann ich mir nicht vorstellen, haste 'nen link?

Jo hast recht. Das war wirklich zur Prä-NT-Ära. Ich habe schon 'ne Weile nichts mehr mit der Win-API gemacht. Auf jeden Fall isses aber neuer als IBM/360.
Die Funktionen waren LoadIcon, CreateIcon etc.

Hallo zusammen!
Vielen Dank für eure Hilfe!
Leider stehe ich aber irgendwie immer noch aufm Schlauch.
Ich bekomme immer noch den "Segmentation fault"-Fehler.

Hab meine Datei mal ausgemistet und aufs nötigste reduziert:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

char **getTitles(int *n){
	char *pfad = "./data.txt";
	char **titles = (char**)malloc(20*sizeof(char * ));
	char *c;
	FILE *f;
	int i = 0;
	f = fopen(pfad, "r");
        if(f==NULL) {
            perror("Error: can't open file.\n");
            }else{
            while(fgets(c, 95, f)!=NULL && i<20) {
		titles[i] = (char*)malloc(96 * sizeof(char));
                strncpy(titles[i],c,95);
                i++;
            }
            fclose(f);
	    *n = i+1;
	    return titles;
        }
}

int main(void){
	int *cntTitles = 0;
	char **titles = getTitles(cntTitles);
	int i;

	for(i=0;i<*cntTitles;i++){
		printf("%s", titles[i]);
	}

	for(i=0;i<*cntTitles;i++){
		free(titles[i]);
	}
	free(titles);
	return EXIT_SUCCESS;
}

Was ist daran noch falsch?

Grüsse klopf-klopf

Tachyon

Auf was zeigt denn Dein Pointer c ?

klopf-klopf

while(fgets(c, 95, f)!=NULL && i<20) {
titles[i] = (char*)malloc(96 * sizeof(char));
strncpy(titles[i],c,95);
i++;
}

auf den String der fgets() eingelesen hat. (Oder?)

Grüsse klopf-klopf

Tachyon

klopf-klopf schrieb:

while(fgets(c, 95, f)!=NULL && i<20) {
titles[i] = (char*)malloc(96 * sizeof(char));
strncpy(titles[i],c,95);
i++;
}
auf den String der fgets() eingelesen hat. (Oder?)

Grüsse klopf-klopf

fgets braucht einen Puffer, in den eingelesen wird. c zeigt aber nicht auf einen Puffer, sondern irgendwo hin.