Here you can leave a comment for the site's owner regarding the site's content, appearance, functioning and, generally, write whatever you think on this. Please stay on topic (“on this” doesn't mean “on anything”) and respect the others.
Please note you can also contact the site's owner using the feedback page.
Please note that premoderation is in effect here.
From Orchid of Malevolence (unverified) Sat Aug 22 09:57:30 2026 UTC
Bug: Heap corruption in load_new_types_db() — crashes on startup with -t
Hi! Found a crash in nokotan 1.05 while setting up a Spartan mirror.
In
src/mimetype.c,load_new_types_db():db_pathsis achar **, so this asks for one byte per element instead ofsizeof(char *)— the buffer comes out 8x too small and everydb_paths[n] = strdup(...)writes past its end.The function is called once per
-tfile and once more unconditionally for/etc/nokotan-types, so a single-tmeans two calls: the second writes 8 bytes at offset 8 of a 2-byte allocation. On musl that's a reliable segfault at startup. Without-tthere's only one call and the write usually fits inside malloc's rounding, so it starts fine — but it's still out of bounds.Repro on Alpine:
Fix:
Two more in
load_types_db(), spotted while reading — I didn't actually trigger either:lastis a locl, buttypes_dbis a global list that persists, solast->next = entdereferences NULL on the first entry of-tplus a non-empty/etc/nokotan-types; mine doesn't exist, sofopenbails o/code> from the tail of theexisting list fixes it.file_pattischar[128]and patterns are read with fgets(line, 128, ...ern plus the prepended/overflows it by a byte viastrcat.strncatwith the remaining room, otime.Can send patches if useful
reply
From Koshelkov Pjotr
Sun Aug 23 07:33:03 2026 UTC
in reply to
this comment
Re: Bug: Heap corruption in load_new_types_db() — crashes on startup with -t
UPD: 1.06 released
What the heck have I done?
I'm fixing it now. As of now I can say that this code's behavior even doesn't conform to the documentation. May be I was very tired idk.
Thanks for your report!
reply
From Vbit (unverified) Sun May 10 18:21:51 2026 UTC
Error
alya/$ make cc -Wall -g -c main.c -o main.o cc -Wall -g -c lexan.c -o lexan.o cc -Wall -g -c syntan.c -o syntan.o cc -Wall -g -c refal_fsm.c -o refal_fsm.o cc -Wall -g -c pmatch.c -o pmatch.o cc -Wall -g -c builtin.c -o builtin.o cc -Wall -g -c exp.c -o exp.o exp.c: In function ‘is_balanced’: exp.c:78:14: error: expected identifier or ‘*’ before ‘false’ 78 | goto false; | ^~~~~ exp.c:96:1: warning: statement with no effect [-Wunused-value] 96 | false: | ^~~~~ exp.c:96:6: error: expected ‘;’ before ‘:’ token 96 | false: | ^ | ; exp.c:106:1: warning: control reaches end of non-void function [-Wreturn-type] 106 | } | ^ make: *** [Makefile:16: exp.o] Error 1 alya/$To fix the error, I had to force make to use gcc with the -ansi flag (I also added -pedantic just in case), otherwise the standard cc compiler complains about the program text not conforming to some modern standard.
It would be better to set CC to gcc -ansi -pedantic by default in the Makefile rather than relying on the symlink.
reply
From Koshelkov Pjotr
Sun May 10 21:15:06 2026 UTC
in reply to
this comment
Re: Error
Well, with -ansi it complains about ``absence'' of strdup...
However, I added
-ansi -pedanticflags, along with-fdiagnostics-color=never -fno-diagnostics-show-caret. It will be released in the next version.Thanks for your report.
UPD: Things are even worse: -ansi -pedantic breaks dynamic linking! strdup can not be found, and it just returns garbage (???). But with -static it works normally. Well, I don't understand anything
Eventually, I realised strdup myself. But can anyone tell me, what's going on with the library version?
reply