Virtuelles File System in C schreiben

LordXearo

Danke für deine Hilfe Seppj.

ich mache noch eine Fehlerbehandlung, ich prüfe ob der Speicher reserviert werden konnte.

if ( Speicher == NULL) ...

Wenn ich das (uint_64t vor malloc oder realloc weglasse, mekert visual studio.
Freu mich schon wenn ich soweit bin, das ganze auch in gcc zum laufen zu bekommen....

Sorry bin gerad kurz angebunden.
Erstmal danke.

SeppJ

LordXearo schrieb:

Wenn ich das (uint_64t vor malloc oder realloc weglasse, mekert visual studio.

Wenn du meinst, es gäbe eine Fehlermeldung bei der Übersetzung, dann benutzt du einen C++-Compiler. Tu das nicht.

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. Da kann man nichts machen, außer es zu ignorieren, da man es besser weiß oder kein VS für C zu benutzen.

Hallo, auch ich bin an der gleichen Aufgabe dran und habe ein ähnliches Problem.

Das mit dem malloc funktioniert bei mir aber das Problem ist wie bekomme ich es hin, den Pfad aufzuteilen?
Also in 2 Pfade, damir ich sie dann einzeln ergänzen kann?

Also wenn ich zB jetzt in Java wäre:

pfad1 = pfad
pfad2 = pfad

store = pfad1 + store
structure = pfad2 + structure

oder so in der Art

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.

LordXearo

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.

Wutz

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

LordXearo

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.

SeppJ

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.

Wutz

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.

LordXearo

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?

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)

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?

SeppJ

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.

Wutz

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

LordXearo

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

SeppJ

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.

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?

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.

SeppJ

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; .