4. Virtuelles File System in C schreiben

Virtuelles File System in C schreiben

  • ?

    Also wenn ich zB jetzt in Java wäre:

    pfad1 = pfad
    pfad2 = pfad

    store = pfad1 + store
    structure = pfad2 + structure

    oder so in der Art

    0
  • ?

    SeppJ schrieb:

    Wenn du meinst, dass deine IDE meinst, das wäre falsch, dann liegt das da dran, dass VS eine IDE für C++ ist und der Hersteller ihm keinen Modus für C spendiert hat.

    Das stimmt so nicht.

    Visual Studio unterstützt zumindest C89, die Dateien müssen dafür aber die Endung .c haben (oder man stellt die Kompilierung explizit auf C um).

    TagBoz schrieb:

    aber das Problem ist wie bekomme ich es hin, den Pfad aufzuteilen?

    Schau dir mal die C-Stringverarbeitungsfunktionen an.

    0
  • L

    TagBoz schrieb:

    Also wenn ich zB jetzt in Java wäre:

    pfad1 = pfad
    pfad2 = pfad

    store = pfad1 + store
    structure = pfad2 + structure

    oder so in der Art

    Hol dir den Speicher mit malloc für beide Pfade.
    Dann den Pfad mit strcpy in den reservierten Speicher schreiben.
    Als letztes noch mit strcat die Dateiendungen hinzufügen.

    Ich schau mal, wie ich VS 2012 auf C umstellen kann.

    0

  • Unter Projekteigenschaften / C/C++ / Komplilierungsart = "/TC".

    0
  • L

    Das ist ja grauenvoll....dann wird es im C98 standard kompiliert, d.h. sowas

    for(int i; ... ) ist nicht mehr gültig...

    Un wenn ich den Typcast bei malloc weglasse mekert er trotzdem.....

    Hilft wohl nichts als das Programm nochmal separat für gcc zu bearbeiten.

    0
  • Mod

    C'ler schrieb:

    SeppJ schrieb:

    Wenn du meinst, dass deine IDE meinst, das wäre falsch, dann liegt das da dran, dass VS eine IDE für C++ ist und der Hersteller ihm keinen Modus für C spendiert hat.

    Das stimmt so nicht.

    Visual Studio unterstützt zumindest C89, die Dateien müssen dafür aber die Endung .c haben (oder man stellt die Kompilierung explizit auf C um).

    Ich weiß, dass der Compiler C89 kann, das habe ich doch im Satz davor gesagt. Ich meinte, dass der Editor Sachen als falsch ankringelt, die in C richtig sind, in C++ aber falsch.

    Da ich VS nicht benutze kann ich beides nur weitergeben aus anderen Quellen, aber ich vertraue den häufigen Beschwerden im Forum darüber eher als dieser einen einzigen Meldung des Gegenteils, von der ich mal annehme, dass du dich auf den Compiler bezogen hast.

    0

  • C'ler schrieb:

    SeppJ schrieb:

    Wenn du meinst, dass deine IDE meinst, das wäre falsch, dann liegt das da dran, dass VS eine IDE für C++ ist und der Hersteller ihm keinen Modus für C spendiert hat.

    Das stimmt so nicht.

    Visual Studio unterstützt zumindest C89, die Dateien müssen dafür aber die Endung .c haben (oder man stellt die Kompilierung explizit auf C um).

    Gemeint war hier natürlich der IDE-Modus für C; und was ist der IDE-Modus?
    Richtig, Intellisense.
    Der Compiler selbst (cl.exe) kann natürlich anhand der Option /TC oder anhand der Dateiendung *.c erkennen, was gemeint ist und macht das dann auch so.
    Der Haken ist aber, dass die Default-Einstellung der IDE VisualStudio eben nicht C sondern C++ ist, und für C gibt es in VS kein Intellisense, da kannst du die Compiler-Optionen korrekt auf C gestellt haben, es nützt alles nichts;
    "fehlende" Casts bei malloc usw. werden angemahnt.

    0
  • L

    Das defragmentieren dieses vfs macht mich fertig....

    Ich habe noch keine Vorstellung wie ich es genau anstellen soll. Erstmal habe ich mir vorgenommen, zu jeder Datei, alle Blöcke zuzordnen, die diese Datei im Store belegt. Habe also bereits ein zwei-dimensionales dynamisches Array angelegt und alles richtig zugeordnet.

    Nun denke ich, dass das mit Großen Dateien nicht hinhauen wird.
    Angenommen ich habe 100 Dateien (Zeilen) und die größte Datei belegt 10.000 Blöcke, also habe ich dann 10.000 Spalten. Jeder dieser werte ist 64Bit lang.

    Das würde einen immensen Speicherplatz benötigen.
    Eine Datei die 10.000 Blöcke belegt, bei der jeder Block eine größe von 4096Byte hat, wäre auch gerade mal ~41MB groß.

    Also erstmal alles in den Speicherladen fällt schonmal flach, hat jemand einen Tipp für mich?

    0
  • ?

    Hallo,

    obwohl das Anlegen bei mir mittlerweile funktioniert gibt valgrind immer noch einige Fehler aus und ich habe einfach keine Vorstellung wie ich diese beseitigen bzw. verstehe nochnichtmal die Fehlerbeschreibung wirklich. Deswegen bitte ich nochmal um eure Hilfe:
    Also mein Code für das CREATE sieht so aus:

    int create(char *pfadVFS, char *groesseBlockString, char
        *anzahlBloeckeString) {
                // 0 Kommando wurde fehlerfrei ausgeführt
                // 1 Anlegen des VFS war nicht möglich (Aus Gründen, die
                // das Hostsystem verursacht hat)
                // 3 Ein VFS mit dem gegebenen Namen existiert bereits

                int groesseBlock, anzahlBloecke;
                int rueckgabe = 0;
		char *pfadStore;
		char *pfadStructure;

                char *pfadStoreErgaenzung = ".store";
		char *pfadStructureErgaenzung = ".structure";
		int laenge;

		laenge = strlen(pfadVFS);

		pfadStore = (char*) malloc(laenge + 7);
		pfadStructure = (char*) malloc(laenge + 10);

		strcpy(pfadStore, pfadVFS);
		strcpy(pfadStructure, pfadVFS);

		strcat(pfadStore, pfadStoreErgaenzung);
		strcat(pfadStructure, pfadStructureErgaenzung);

                rueckgabe = validateCreate(pfadStore, pfadStructure,
                        groesseBlockString, anzahlBloeckeString);

		if(rueckgabe != 0) {
                        return rueckgabe;
                }

                groesseBlock = atoi(groesseBlockString);
                anzahlBloecke = atoi(anzahlBloeckeString);

                rueckgabe = storeDateiErzeugen(pfadStore, groesseBlock, anzahlBloecke);
                if(rueckgabe !=0) {
                        return rueckgabe;
                }
                rueckgabe = structureDateiErzeugen(pfadStructure, groesseBlock,
                        anzahlBloecke);
                if(rueckgabe !=0) {
                        return rueckgabe;
                }

		free(pfadStore);
		free(pfadStructure);
                return 0;
}

    Die valgrind-Hinweise sehen so aus:

    ==6766== Memcheck, a memory error detector
==6766== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==6766== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==6766== Command: /tmp/number-a.out /tmp/testarchiv create 4096 40
==6766== 
==6766== Invalid write of size 1
==6766==    at 0x48DBDA7: strcat (mc_replace_strmem.c:176)
==6766==    by 0x804A9EB: create (1376505601.c:1293)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766==  Address 0x6d1f09a is 0 bytes after a block of size 34 alloc'd
==6766==    at 0x48DAF50: malloc (vg_replace_malloc.c:236)
==6766==    by 0x804A9A0: create (1376505601.c:1287)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766== 
==6766== Invalid read of size 1
==6766==    at 0x48DC0C3: strlen (mc_replace_strmem.c:282)
==6766==    by 0x49515F1: vfprintf (vfprintf.c:1617)
==6766==    by 0x495822F: printf (printf.c:35)
==6766==    by 0x804AA13: create (1376505601.c:1295)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766==  Address 0x6d1f09a is 0 bytes after a block of size 34 alloc'd
==6766==    at 0x48DAF50: malloc (vg_replace_malloc.c:236)
==6766==    by 0x804A9A0: create (1376505601.c:1287)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766== 
==6766== Syscall param open(filename) points to unaddressable byte(s)
==6766==    at 0x49CD97E: __open_nocancel (syscall-template.S:82)
==6766==    by 0x4978897: _IO_file_fopen@@GLIBC_2.1 (fileops.c:336)
==6766==    by 0x496CB9C: __fopen_internal (iofopen.c:93)
==6766==    by 0x496CBFB: fopen@@GLIBC_2.1 (iofopen.c:107)
==6766==    by 0x804AB20: validateCreate (1376505601.c:1343)
==6766==    by 0x804AA33: create (1376505601.c:1299)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766==  Address 0x6d1f09a is 0 bytes after a block of size 34 alloc'd
==6766==    at 0x48DAF50: malloc (vg_replace_malloc.c:236)
==6766==    by 0x804A9A0: create (1376505601.c:1287)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766== 
==6766== 
==6766== HEAP SUMMARY:
==6766==     in use at exit: 65 bytes in 2 blocks
==6766==   total heap usage: 4 allocs, 2 frees, 769 bytes allocated
==6766== 
==6766== 31 bytes in 1 blocks are definitely lost in loss record 1 of 2
==6766==    at 0x48DAF50: malloc (vg_replace_malloc.c:236)
==6766==    by 0x804A98F: create (1376505601.c:1286)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766== 
==6766== 34 bytes in 1 blocks are definitely lost in loss record 2 of 2
==6766==    at 0x48DAF50: malloc (vg_replace_malloc.c:236)
==6766==    by 0x804A9A0: create (1376505601.c:1287)
==6766==    by 0x804AEED: main (1376505601.c:1468)
==6766== 
==6766== LEAK SUMMARY:
==6766==    definitely lost: 65 bytes in 2 blocks
==6766==    indirectly lost: 0 bytes in 0 blocks
==6766==      possibly lost: 0 bytes in 0 blocks
==6766==    still reachable: 0 bytes in 0 blocks
==6766==         suppressed: 0 bytes in 0 blocks
==6766== 
==6766== For counts of detected and suppressed errors, rerun with: -v
==6766== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 15 from 8)
    0
  • ?

    Vielleicht mal die erste Frage: Warum steht da, dass ich 4mal malloc und 2mal free benutze. Das scheint ein Problem zu sein. Aber ich benutze doch nur 2mal malloc?

    0
  • Mod

    Viele Pfade führen aus deiner Funktion, bei denen der Speicher nicht korrekt freigegeben wird. Weiterhin schreibst du irgendwo hinter ein von dir reserviertes Feld, was ebenfalls ein sehr ernstes Problem ist. Die Zeilennummern sagen dir, wo.

    0

  • Du zeigst nicht den ganzen Code.
    Außerdem kannst du auch nicht rechnen, +10 ist zu klein.

    0
  • L

    Es sollen auch 64Bit lange Datentypen verwendet werden, weil das Programm auch mit Gigabyte bzw. Terrabyte großen Dateien klar kommen soll.

    0
  • Mod

    Wutz schrieb:

    Außerdem kannst du auch nicht rechnen, +10 ist zu klein.

    Ahh, ich kann doch noch zählen :p . Ich hatte schon gedacht, so ein dummer Fehler kann's nicht sein.

    Daher benutzt man besser eine narrensichere Methode, die die nötige Größe bestimmt, anstatt dass man selber zählt. Dann kann man das Literal später auch noch ändern und es funktioniert trotzdem noch.

    0
  • ?

    Wutz schrieb:

    Du zeigst nicht den ganzen Code.
    Außerdem kannst du auch nicht rechnen, +10 ist zu klein.

    Aha "structure" = 9 + 1 für das Ende-Zeichen = 10
    Was ist daran falsch?

    0
  • ?

    SeppJ schrieb:

    Viele Pfade führen aus deiner Funktion, bei denen der Speicher nicht korrekt freigegeben wird. Weiterhin schreibst du irgendwo hinter ein von dir reserviertes Feld, was ebenfalls ein sehr ernstes Problem ist. Die Zeilennummern sagen dir, wo.

    Wie meinst du das? Ich reserviere mir doch direkt den ganzen Speicher den ich brauche...und ich habe überprüft ob die Pfade richtig zusammengebaut werden.

    0
  • Mod

    C_Mond schrieb:

    Wutz schrieb:

    Du zeigst nicht den ganzen Code.
    Außerdem kannst du auch nicht rechnen, +10 ist zu klein.

    Aha "structure" = 9 + 1 für das Ende-Zeichen = 10
    Was ist daran falsch?

    Aber da steht nicht "structure". Guck noch mal genau hin. Und bevor du das jetzt einfach zu 11 änderst, denkst du mal daêüber nach, wie du das besser machen könntest, ohne magic numbers. Und damit meine ich nicht const int length = 11; .

    0
  • Mod

    C_Mond schrieb:

    SeppJ schrieb:

    Viele Pfade führen aus deiner Funktion, bei denen der Speicher nicht korrekt freigegeben wird. Weiterhin schreibst du irgendwo hinter ein von dir reserviertes Feld, was ebenfalls ein sehr ernstes Problem ist. Die Zeilennummern sagen dir, wo.

    Wie meinst du das? Ich reserviere mir doch direkt den ganzen Speicher den ich brauche...und ich habe überprüft ob die Pfade richtig zusammengebaut werden.

    Ja, du reservierst den Speicher. Das ist ja das Problem, denn er wird nicht mehr unbedingt frei gegeben. Bloß in einem von vier Fällen, die ich sehe. Und da zähle ich mögliche, mir unbekannte, Nebeneffekte von storeDateiErzeugen nicht mit.

    Ich glaube, dir täte mal etwas Strukturierung gut:
    http://en.wikipedia.org/wiki/Structured_programming
    Dogmatisches Anhängen an strukturierter Programmierung ist zwar etwas aus der Mode, aber das liegt nicht da dran, dass es schlecht wäre, sondern da dran, dass es praktisch jeder so beigebracht bekommen hat und ohnehin immerzu benutzt und man dadurch die paar Ausnahmen deutlich sieht, in denen es nicht die beste Vorgehensweise ist.
    Du hast derzeit sehr viele verschiedene Ausführungspfade und scheinst selber total den Überblick verloren zu haben, wenn du mit meinem Hinweis nichts anfangen konntest.

    0
  • ?

    Okay ich bin nun mal ein Neuling sonst wäre ich ja nicht hier um Hilfe zu suchen.
    Den Code fand ich bis jetzt eigentlich übersichtlich.

    Könntest du mir einfach mal die 4 Fälle nennen die du siehst?

    0
  • ?

    Alle return, die vor den free stehen.

    0
Anmelden zum Antworten