Einloggen
[c] [test] [fefe]

/c/ – Pufferüberlauf


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Quellcodeklebrig? Frickelfelix Wed, 02 Jan 2019 23:05:00 GMT Nr. 5853 Klebrig
    PNG 623×714 235.4k
    Schraubt hier jemand außer Zuse am DC-Quelltext?

    Die Projektziele haben mir gefallen und obwohl Portabilität nicht mit aufgeführt wird und ausdrücklich Linux gefordert, habe ich mal versucht, es auf meinem LSD zum laufen zu bekommen. Auf die namensgebende Diäten-Libc kann man verzichten, libowfat und Abhängigkeiten sind als Paket vorhanden.

    Kleinere Unterschiede , wie dass
    * sich include- und lib-Pfade unterscheiden,
    * BSD-gcc alt ist und z.B. -mmititage-rop nicht unterstützt,
    * einige Bibos in BSD nicht existieren, oder dass
    * Funktionsprototypen für malloc und alloca nicht in eigenen Header-Dateien liegen,

    lassen sich trivial lösen. Gestoppt habe ich jetzt, bei fallocate (z.B. db.c:398). Vielleicht kann man es einfach ein #ifdef _GNU_SOURCE eingefassen, aber was war hier die Absicht des Verfassers?

    Was hält Felix von einem Klebefaden für Quellcodefrickler? Wenn man auf Gitgud schaut, könnte das Projekt Aufmerksamkeit und Zuarbeiter gebrauchen (issues == mergereqs == 0).
  • [l] Frickel- Felix Wed, 02 Jan 2019 23:12:22 GMT Nr. 5854 SÄGE
    Es hätte heißen sollen
    >wühlt hier sonst jemand in den Eingeweiden von...
    dann passt die Katze auch dazu.

    Bin ansonsten schwer von der bereites erledigten Arbeit begeistert. Bitte empfangt mein kameradschaftliches Tele-Schulterklopfen.
  • [l] Zuse ## Admin Wed, 02 Jan 2019 23:25:32 GMT Nr. 5855
    Ich finde es auf jeden Fall kühl, wenn andere daran mitfrickeln. Danke schon mal für deine Erkenntnisse.

    Das fallocate ist da, weil die Datei per mmap in den Speicher gemappt wird. Ohne fallocate gäbe es dann beim Zugriff einen Bus-Error. Die gleiche Funktionalität müsste doch aber auch unter BSD möglich sein?

    In db.c könnte man eh ein paar Sachen verbessern. Z.B. wird die Datei im Moment zwei mal ein den Speicher gemappt, wobei die eine Kopie nur zum Zurückschreiben der Daten auf die Platte dient. Das ist eigentlich unnötig, da könnte man auch einfach write(), seek() und Co. verwenden.

    Außerdem hat sich herausgestellt, dass fsync auf dem Raspberry Pi sehr langsam ist (das Syncen der Datenbank braucht so ungefähr eine Sekunde und in dieser Zeit können keine Requests bearbeitet werden). Man könnte das vielleicht in einem Hintergrundthread oder so erledigen.

    Habe den Faden mal angepinnt.
  • [l] Frickel- Felix Thu, 03 Jan 2019 13:31:00 GMT Nr. 5874
    Du wirst deine Gründe dafür haben, aber dass es zwei db_init-Prototypen gab, war für mich eine Stolperfalle. fallocate(2) ist erstmal rausgeflogen, es kompiliert und ich bin beim genannten Bus-Problem.

    >gleiche Funktionalität unter BSD
    Gibt es bestimmt. Zumindest kann man auch ohne fallocate mit mmap in Dateien schreiben. Ich habe mal versucht, das Problem mit einem einfachen Programm nachzubauen:
    #include <unistd.h>
    #include <fcntl.h>
    #include <sys/mman.h>
    #include <string.h>
    
    int main(void)
    {
            int fd = open("test_file", O_RDWR | O_CREAT, (mode_t)0600);
            const char *text = "hello";
            size_t textsize = strlen(text) + 1;
            lseek(fd, textsize-1, SEEK_SET);
            /*write(fd, "", 1);*/
            char *map = mmap(0, textsize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
            memcpy(map, text, strlen(text));
            msync(map, textsize, MS_SYNC);
            munmap(map, textsize);
            close(fd);
            return 0;
    }
    

    fallocate wäre hier write. Wenn es auskommentiert ist, kommt es zum Fehler.
  • [l] Bonus-Frickel- Felix Thu, 03 Jan 2019 14:06:46 GMT Nr. 5875
    Da ich bei mir die mitgelieferten Fefe-Libs ignorieren kann (da BSD-Clib vorhanden und libowfat vorinstalliert), fuhrwerke ich direkt in dietchan/src/dietchan/src rum und da ist mir cmake nach einer Weile auf den Senkel gegangen, weil man nach vielen kleineren Änderungen immer das Makefile neu generieren musste. Meine Variante ist sicher nicht perfekt, aber reicht zum kompilieren:
    CC=gcc
    CFLAGS=-I/usr/local/include -pedantic -std=c99 -O0 -ggdb
    OBJS=arc4random.o bans.o bbcode.o captcha.o context.o db.o db_hashmap.o \
        dietchan.o export.o http.o import.o ip.o job.o mime_types.o \
        params.o permissions.o persistence.o print.o session.o \
        tpl.o upload_job.o util.o
    POBJS=pages/banned.o pages/board.o pages/dashboard.o pages/edit_board.o pages/edit_user.o pages/login.o pages/mod.o pages/post.o pages/static.o pages/thread.o 
    dietchan: $(OBJS) $(POBJS)
            $(CC) -o dietchan -L/usr/local/lib -lowfat $(OBJS) $(POBJS:S/pages\///g)
    
    clean:
            rm -f $(OBJS) $(POBJS:S/pages\///g) dietchan
    

    Hab's auch mit clang geprüft. Kompiliert und die Fehlermeldungen sind dieselben :)

    Auch: rsync benutzt fallocate (--preallocate), allerdings optional.

    Wa alles, beste Grüße
  • [l] Zuse ## Admin Thu, 03 Jan 2019 16:53:35 GMT Nr. 5876
    >>5874
    >Du wirst deine Gründe dafür haben, aber dass es zwei db_init-Prototypen gab
    Hmm, nein, eigentlich nicht. Weiß selber nicht mehr, warum das so ist. Vielleicht war es mal irgendwas zum debuggen, was ich danach nur unvollständig wieder entfernt habe.

    Bezüglich CMake: Zum Entwickeln am besten in src/dietchan wechseln und dort bauen. So habe ich es immer gemacht. Die ExternalProjekt-Funktion von CMake scheint irgendwie etwas verkäfert zu sein. Ich wollte aber etwas haben, was man einfach runterladen und kompilieren kann. Mit dietlibc ist das alles etwas schwierig.
  • [l] Felix Sat, 05 Jan 2019 22:13:28 GMT Nr. 5936
    PNG 512×512 16.6k
    >Mit dietlibc ist das alles etwas schwierig.
    Elaboriere "das alles". Gibt's kein 'make install' oder tut es einfach nicht das Richtige?

    Ich versuche es immer noch zum laufen zu bekommen. Ich schreibe wie im Beispiel gleich nach dem Öffnen in die neue Datei und der Bus-Error ist verschwunden. Jetzt ist ein neuer in db_hashmap_init und wieder mit byte_zero().
  • [l] Zuse ## Admin Sun, 06 Jan 2019 04:11:51 GMT Nr. 5938
    >>5936
    Du brauchst nicht nur dietlibc, sondern auch die richtige Version. Zum Zeitpunkt der Veröffentlichung war das die Trunk-Version und nun die 0.34, weil in der damals aktuellen Version 0.33 noch einige Sachen nicht implementiert waren (z.B. SHA-Hashes und die Race-Condition-freie Version von realpath()). Außerdem muss libowfat dann auch gegen dietlibc gelinkt sein. Das ist alles nicht unbedingt gegeben, wenn man aus einem Repository installiert. Dependencies zu installieren ist sowieso immer mühsam. Ich wollte die Einstiegshürde so gering wie möglich halten. Man sollte es einfach runterladen können und einen Befehl ausführen können, um es zu kompilieren.

    >Ich versuche es immer noch zum laufen zu bekommen. Ich schreibe wie im Beispiel gleich nach dem Öffnen in die neue Datei und der Bus-Error ist verschwunden. Jetzt ist ein neuer in db_hashmap_init und wieder mit byte_zero().
    Versuch mal, die Datei gleich am Anfang auf eine größere Größe zu initialisieren. Die Datei wächst nämlich dynamisch, während sie gefüllt wird. Ich glaube, es ist aber offiziell undefiniertes Verhalten, wie mmap sich verhält, wenn man über das Dateiende hinausmappt (wusste ich zu dem Zeitpunkt aber auch nicht). Beispiel: Sagen wir mal du mappst 10 MB, aber deine Datei ist nur 2 MB groß. POSIX gibt dir die Garantie, dass du auf die ersten 2 MB zugreifen kannst. Wenn jetzt aber die Datei auf 4 MB wächst, dann ist nach POSIX nicht garantiert, dass du auf mehr als die ersten 2 MB zugreifen kannst, obwohl die 4 MB noch in den gemappten 10 MB sind. Unter Linux funktioniert es aber. Vielleicht geht das unter BSD nicht.

    Lösung könnte sein, nach dem Vergrößern der Datei mmap erneut aufzurufen, mit MAP_FIXED als Flag. Dummerweise gibt es aber wiederum keine Garantie, dass MAP_FIXED auch beachtet wird. Aber solange sich die gemappte Größe nicht ändert, sehe ich keinen Grund, warum ein Betriebssystem das Flag nicht beachten sollte.

    Ich würde es erst mal zum Testen damit probieren, die Datei gleich zu Anfang auf eine größere Größe zu initialisieren, z.B. auf 10 MB. Das sollte reichen (die db von dietchan.org ist aktuell 2.1 MB groß).
  • [l] Zuse ## Admin Sun, 06 Jan 2019 09:57:57 GMT Nr. 5939
    Ich habe mal ein paar der angesprochenen Dinge geändert. Probier mal die neue Version.

    Falls hier demnächst etwas kaputt geht, wisst ihr woran es lag.
  • [l] Zuse ## Admin Sun, 13 Jan 2019 16:44:48 GMT Nr. 6155
    Bist du inzwischen weitergekommen?
  • [l] Frickel- Felix Mon, 14 Jan 2019 18:41:12 GMT Nr. 6183
    JPG 600×600 102.6k
    Leider noch nicht.

    Gerade ist daheim das Internet futsch, was die Freizeitprojekte etwas ausbremst.
  • [l] Frickel- Felix Sun, 20 Jan 2019 10:16:41 GMT Nr. 6344
    Wenn ich das richtig sehe, dann hast du die Bibliotheken aus dem Projekt entfernt. Hier ein Ansatz für dietchan/Makefile, um die aktuellen Bibliotheken herunterzuladen, verifizieren und zu entpacken:
    FETCH=curl -O
    VERIFY=gpg --verify
    LFVER=0.32
    LFURI=http://www.fefe.de/libowfat/
    DLVER=0.34
    DLURI=http://www.fefe.de/dietlibc/
    
    libs: libowfat-$(LFVER) dietlibc-$(DLVER)
    
    libowfat-$(LFVER): libowfat-$(LFVER).tar.xz libowfat-$(LFVER).tar.xz.sig
    	$(VERIFY) libowfat-$(LFVER).tar.xz.sig
    	xzcat libowfat-$(LFVER).tar.xz | tar xf -
    
    dietlibc-$(DLVER): dietlibc-$(DLVER).tar.xz dietlibc-$(DLVER).tar.xz.sig
    	$(VERIFY) dietlibc-$(DLVER).tar.xz.sig
    	xzcat dietlibc-$(DLVER).tar.xz | tar xf -
    
    libowfat-$(LFVER).tar.xz:
    	$(FETCH) $(LFURI)$@
    
    libowfat-$(LFVER).tar.xz.sig:
    	$(FETCH) $(LFURI)$@
    
    dietlibc-$(DLVER).tar.xz:
    	$(FETCH) $(DLURI)$@
    
    dietlibc-$(DLVER).tar.xz.sig:
    	$(FETCH) $(DLURI)$@
    

    Zum Verifizieren braucht man natürlich den Schlüssel (von Fefes Seite holen oder mit gpg --search-key A534A9C6 suchen und importieren).
    Kann es sein, dass GPG bei nicht erfolgreicher Verifizierung trotzdem null zurückgibt? Auch würde ich gerne die letzten vier Regeln in eine zusammenfassen, komme aber gerade nicht drauf wie.
  • [l] Frickel- Felix Fri, 01 Mar 2019 20:45:53 GMT Nr. 8024
    Ich habe jetzt eine BSD- und eine Linux-Installation und bin soweit ohne CMake klargekommen. Makefile aus >>5875 funktioniert mit einigen Anpassungen. Ich beschreibe den Vorgang im nächsten Pfosten. Hier noch einige Anregungen:

    1. Erste Meldung: "Listening on 127.0.0.1:4000 (try /c)" ist klickbar und deutet gleich auf's Standardbrett
    2. dietchan startet eine unschöne Endlosschleife, wenn captcha im Ordner fehlt (generate_captchas ist bei mir deshalb auskommentiert).
    3. Es wäre schon, wenn der Quelltext wirklich in /src zu finden wäre. captcha kann meinetwegen fliegen. Es ist ein eigenständiges Projekt und man kopiert nur die fertige Datei zu herüber.
  • [l] Frickel- Felix Fri, 01 Mar 2019 20:48:10 GMT Nr. 8025
    Dietchan zu kompilieren ist nicht schwierig. Ohne Vorkenntnisse sollte man nach 10-15 Minuten mit dem Hacken anfangen können. Ich habe das hier mal etwas ausführlicher beschrieben:

    1. DIETLIBC

    Lade dir die aktuelle Version (zur Zeit 0.34) von http://www.fefe.de/dietlibc .

    Falls du ihn noch nicht hast, solltest du auch seinen PGP-Schlüssel A534A9C6 laden. Das geht entweder über die Seite selbst (https://dl.fefe.de/felix@fefe.de.asc, du musst ihn noch mit "gpg --import" einlesen) oder mit dem Befehl "gpg --search-key 0xA534A9C6". Kannst du den Schlüssel dann in der Ausgabe von "gpg -k Fefe" finden, kannst du ebenso mit "gpg --verify dietlibc-0.34.tar.xz" die Echtheit des Pakets prüfen.

    Hat GPG nichts zu beanstanden, entpackst du das Archiv, wechselst in das neue Verzeichnis und führst "make" aus. Wenn du hier einen Fehler bekommst, dann hast du vermutlich die Kernel-Header nicht installiert. Ist alles glatt gelaufen, dann schaust du in den Ordner bin-x86 oder bin-x86_64 und wirst dort eine Datei mit dem Namen diet finden. Mit ihrer Hilfe können wir ohne großer Friemelei Dateien mit der dietlibc kompilieren, indem wir einfach das Wort diet vor den gcc-Befehl schreiben.

    Du solltest wissen, wie du auf deinem System diese Datei in deinen Suchpfad kopieren kannst. Tue dies! Nur falls du dies nicht weißt, probier es mit folgendem:
    1. Lege dir ein Verzeichnis ~/bin an.
    2. Starte eine Shell und schreibe PATH=$PATH:~/bin .
    3. Kopiere die diet-Datei nach ~/bin .
    4. Probiere testweise im entpackten Archiv folgendes: "diet -v gcc t.c"
    Dietlibc schreibt einige Warnungen, die uns jetzt nicht interessieren. Schau, ob eine Datei t entstanden ist und ob sie läuft.

    Gut! Du hast jetzt diet in deinem Suchpfad und kannst theoretisch allerhand Dateien mit der Dietlibc kompilieren und auf diese Weise viel kleinere ausführbare Datei erzeugen.

    2. LIBOWFAT

    Sehr einfach: Herunterladen, Verifizieren, Entpacken und make ausführen. Wenn du im letzten Schritt alles richtig gemacht hast, dann wird diet im Suchpfad erkannt und genutzt.

    3. DIETCHAN

    Besorg dir den Kot, indem du das Git-Repositorium klonierst:
    git clone https://gitgud.io/zuse/dietchan.git
    Der eigentliche Quellkot liegt im Unterverzeichnis dietchan/src. Wir machen es uns jetzt sehr einfach und kopieren das Verzeichnis libowfat-0.32/libowfat und die Datei libowfat.a ins dietchan-Verzeichnis. Dann gehst du in das src-Verzeichnis und das "make" sollte ohne Probleme durchlaufen und eine Datei dietchan erzeugen. Wenn du diese ausführst, kannst du in deinem Brausierer die Adresse "127.0.0.1:4000/c" öffnen et voila!

    Du siehst, es ist nicht schwierig. Vielleicht konntest du Einiges überspringen, weil du es schon kennst. Du kannst jetzt jedenfalls alles.jpg im Quelltext verändern. Versuche zum Beispiel mal die Seitenunterschrift ("Proudly made...") zu ändern und pfostiere dein Ergebnis hier.
  • [l] Frickel- Felix Fri, 01 Mar 2019 20:52:14 GMT Nr. 8026
    Der Vollständigkeit halber, die veränderte Make-Datei:
    CC=diet gcc
    CFLAGS=-I.. -pedantic -std=c99 -O0 -ggdb
    OBJS=arc4random.o bans.o bbcode.o captcha.o context.o db.o db_hashmap.o \
        dietchan.o export.o http.o import.o ip.o job.o mime_types.o \
        params.o permissions.o persistence.o print.o session.o \
        tpl.o upload_job.o util.o
    POBJS=pages/banned.o pages/board.o pages/dashboard.o pages/edit_board.o pages/edit_user.o pages/login.o pages/mod.o pages/post.o pages/static.o pages/thread.o 
    dietchan: $(OBJS) $(POBJS)
    	$(CC) -o dietchan $(OBJS) $(POBJS) -L.. -lowfat
    
    clean:
    	rm -f $(OBJS) $(POBJS) dietchan
    


    Es ist jetzt an die einfacheren Gegebenheiten angepasst und berücksichtigt, dass die Pfade nicht von POBJS nicht angepasst werden müssen.

    Nochmal zum letzten Pfosten: Stimmt der Git-Pfad so?
  • [l] Zuse ## Admin Sat, 02 Mar 2019 19:48:02 GMT Nr. 8038
    >>8024
    >1. Erste Meldung: "Listening on 127.0.0.1:4000 (try /c)" ist klickbar und deutet gleich auf's Standardbrett
    Ist ein guter Vorschlag, werde ich wohl umsetzen.
    >2. dietchan startet eine unschöne Endlosschleife, wenn captcha im Ordner fehlt (generate_captchas ist bei mir deshalb auskommentiert).
    Eine Endlos-Schleife ist es nicht, aber es ist etwas spammig, das gebe ich zu. Wäre besser, wenn die Captchas erst generiert würden, wenn sie wirklich gebraucht werden.
    >3. Es wäre schon, wenn der Quelltext wirklich in /src zu finden wäre.
    Hmm, die Logik ist, dass sich in dem Ordner die Quellen zu den Teilkomponenten befinden. Normalerweise sind dies: dietlibc, libowfat, dietchan selbst und das captcha. Da du dietlibc und libowfat aber manuell kompiliert hast, ist das vielleicht bei dir etwas irritierend.

    Danke auf jeden Fall für deine Ausführungen :-) Hast du etwas bestimmtes mit der Software vor?
  • [l] Felix Tue, 05 Mar 2019 17:56:39 GMT Nr. 8087
    >>8038
    Stimmt der Git-Pfad so? Bin mit Git noch nicht ganz warm.

    >Hast du etwas bestimmtes mit der Software vor?
    Ja, C-Praxis bekommen. Vielleicht hast du bei Linux schon von den Kernel-Putzen gehört.

  • [l] Zuse ## Admin Wed, 06 Mar 2019 16:54:39 GMT Nr. 8148
    >>8087
    >Stimmt der Git-Pfad so? Bin mit Git noch nicht ganz warm.
    Sollte stimmen. Wenn es funktioniert, dann stimmt es auch.
  • [l] Frickelfelix Fri, 29 Mar 2019 21:32:32 GMT Nr. 9101
    diff --git a/src/dietchan/src/dietchan.c b/src/dietchan/src/dietchan.c
    index 46727cc..68ad8d2 100644
    --- a/src/dietchan/src/dietchan.c
    +++ b/src/dietchan/src/dietchan.c
    @@ -246,7 +246,7 @@ int handle_write_events(int limit)
     		if (!ctx) {
     			io_dontwantwrite(s);
     			io_close(s);
    -			printf("Warning: cookie is null\n");
    +			buffer_putsflush(buffer_2, "Warning: cookie is null\n");
     			continue;
     		}
     		context_flush(ctx);
    @@ -258,8 +258,11 @@ void add_listener(struct ip ip, uint16 port)
     {
     	char buf[256];
     	buf[fmt_ip(buf,&ip)] = '\0';
    -	fprintf(stderr, "Creating listener on port %d for address %s\n", (int)port, buf);
    -
    +	buffer_puts(buffer_2, "Creating listener (try http://");
    +	buffer_puts(buffer_2, buf);
    +	buffer_puts(buffer_2, ":");
    +	buffer_putulong(buffer_2, (unsigned long)port);
    +	buffer_putsflush(buffer_2, "/c for the default board).\n");
     	struct listener *listener = listeners + listener_count;
     	listener->ip = ip;
    
  • [l] Zuse ## Admin Sat, 30 Mar 2019 00:54:43 GMT Nr. 9103
    >>9101
    Danke, ist drin.
  • [l] Felix Wed, 24 Apr 2019 12:54:18 GMT Nr. 10061
    GIF 600×400 104.5k
    Kannst du für einen guten NichtInformatiker etwas zu deiner Datenbank sagen?

    Verstehe das so, dass sie dynamisch Speicher alloziert und zwar eimerweise :> Funktion eines Journals ist schon von Dateisystemen her bekannt. Die persistence.h verstehe ich so, dass praktisch alle Anfragen an die Datenbank dort gebündelt sind. Serialisierung fällt flach, weil die Datenstruktur auf der Platte dank mmap dieselbe wie im Speicher ist.

    Gibt es ein Vorbild?
  • [l] Zuse ## Admin Thu, 25 Apr 2019 03:41:18 GMT Nr. 10078
    >>10061
    Du hast es erfasst. Die Datenbank ist sozusagen ein Dump des Speicherabbildes.

    >Gibt es ein Vorbild?
    Das Design war ein bisschen von BerkeleyDB inspiriert. Ich weiß aber nicht viel über BerkeleyDB, habe es auch nie benutzt.
  • [l] Felix Mon, 29 Apr 2019 23:13:01 GMT Nr. 10176
    Kurze Frage: Kann es sein, dass der Quelltext
    https://gitgud.io/zuse/dietchan/blob/master/src/dietchan/src/db.c#L568-582
    niemals ausgeführt wird, weil die Schleife darüber immer entweder zu
    success
    oder
    fail
    springt?
  • [l] Zuse ## Admin Tue, 30 Apr 2019 10:20:45 GMT Nr. 10185
    >>10176
    Gut aufgepasst, der Code machte auf jeden Fall keinen Sinn.

    Eigentlich müssen die Seiten sowieso nur nach einem Crash neu gemappt werden (im laufenden Betrieb wächst die Datenbank sonst einfach in den anonym gemappten Bereich hinein), dann aber immer, unabhängig davon, ob sich die Größe geändert hat. Ich habe das mal behoben. Ich habe den Code länger nicht mehr angeschaut, aber glaube es stimmt so.

    Es sind eh im Hintergrund Änderungen am Journal im Gange, ist aber alles noch experimentell.

    Vielen Dank für den Hinweis!
  • [l] Frickel- Felix Sat, 01 Jun 2019 12:15:39 GMT Nr. 11247
    Hai, Konni!

    Hab mal wieder gebaut und mit dem aktuellen Kot läuft die Kiste auch auf BSD.

    diff --git a/src/dietchan/src/config.h b/src/dietchan/src/config.h
    index 9f64c30..4c3af42 100644
    --- a/src/dietchan/src/config.h
    +++ b/src/dietchan/src/config.h
    @@ -75,5 +75,6 @@
     #define MAX_GET_PARAM_LENGTH           2048
     #define MAX_POST_PARAM_LENGTH         16384
     #define MAX_MULTIPART_BOUNDARY_LENGTH   128
    +#define NEED_CAPTCHA                      0
     
     #endif // CONFIG_H
    diff --git a/src/dietchan/src/dietchan.c b/src/dietchan/src/dietchan.c
    index 65be601..64ce7ed 100644
    --- a/src/dietchan/src/dietchan.c
    +++ b/src/dietchan/src/dietchan.c
    @@ -380,7 +380,7 @@ int main(int argc, char* argv[])
     	mkdir(DOC_ROOT "/uploads", 0755);
     	mkdir(DOC_ROOT "/captchas", 0755);
     	// Start generating captchas
    -	generate_captchas();
    +	if (NEED_CAPTCHA) generate_captchas();
     
     	// Main loop
     	while (1) {
    

    Eigentlich sollte das nur auskommentiert werden, aber wir haben ja schon eine config.h.

    diff --git a/src/dietchan/src/http.c b/src/dietchan/src/http.c
    index c141d33..f82f55f 100644
    --- a/src/dietchan/src/http.c
    +++ b/src/dietchan/src/http.c
    @@ -1,6 +1,8 @@
     #include "http.h"
     
    +#ifdef __GLIBC__
     #include <alloca.h>
    +#endif
     #include <string.h>
     #include <stdlib.h>
     #include <ctype.h>
    

    Anscheinend ist alloca.h GLIBC-spezifisch und ich habe überlegt, wie man das umsetzen kann. Wörksformi(tm), aber jetzt fange ich an, den Kot mit ifdefs zu verschandeln. Ich habe mal gelesen, dass das schöner geht, kann mich aber nicht daran erinnern wie.

    diff --git a/src/dietchan/src/import.c b/src/dietchan/src/import.c
    index eab0a6f..a0ca7a2 100644
    --- a/src/dietchan/src/import.c
    +++ b/src/dietchan/src/import.c
    @@ -1,6 +1,5 @@
     #include "import.h"
     
    -#include <malloc.h>
     #include <unistd.h>
     #include <ctype.h>
     #include <stdio.h>
    

    Einbinden von malloc.h ist angeblich auch auf Linux mittlerweile unerwünscht, also habe ich es einfach ausgelassen.

    diff --git a/src/dietchan/src/pages/post.c b/src/dietchan/src/pages/post.c
    index 2971796..16acadc 100644
    --- a/src/dietchan/src/pages/post.c
    +++ b/src/dietchan/src/pages/post.c
    @@ -1,9 +1,8 @@
    -#define _BSD_SOURCE 1
    +#define _BSD_SOURCE 1
     #define _GNU_SOURCE 1
     #define _XOPEN_SOURCE 1
     #include "post.h"
     
    -#include "malloc.h"
     #include <stdio.h>
     #include <sys/socket.h>
     #include <sys/stat.h>
    

    In post.c hat sich ein BOMЖ verirrt, an dem sich gcc verschluckt.

    Das "malloc.h" habe ich aus demselben Grund ausgelassen, warum ist es hier allerdings in ""?

    diff --git a/src/dietchan/src/util.c b/src/dietchan/src/util.c
    index 3802858..b6c78ab 100644
    --- a/src/dietchan/src/util.c
    +++ b/src/dietchan/src/util.c
    @@ -1,11 +1,15 @@
     #include "util.h"
     
     #include <ctype.h>
    +#ifdef __GLIBC__
     #include <alloca.h>
    +#endif
     #include <libowfat/str.h>
     #include <libowfat/fmt.h>
     #include <libowfat/scan.h>
    +#ifndef arc4random
     #include "arc4random.h"
    +#endif
     
     size_t byte_str(const char *haystack, size_t haystack_length, const char *needle)
     {
    

    Keine Ahnung, ob das so funktioniert. In BSD wird arc4random in der stdlib.h definiert, also sollte er die eigene Definition nicht einbinden.
  • [l] Zuse ## Admin Sat, 01 Jun 2019 22:51:18 GMT Nr. 11254
    >>11247
    Danke erstmal. Sieht soweit gut aus, das mit den Captchas könnte aber Probleme geben, wenn man sie zur Laufzeit aktiviert und NEED_CAPTCHAS nicht gesetzt ist. Ich denke, die richtige Lösung wäre, dass die Captchas generiert werden, wenn sie zum ersten mal aktiviert werden.
  • [l] Zuse ## Admin Fri, 14 Jun 2019 04:18:25 GMT Nr. 11668
    Kurzes Update, ich habe erstmal diese Header-Sachen da gefixt. Es hat sich außerdem rausgestellt, dass auch dietlibc mittlerweile eine arc4random-Implementierung mitliefert, sodass ich den Kot komplett entfernen konnte. Das ist immer erfreulich.


[Zurück]
[c] [test] [fefe]