3 ms·
fixed ONLY the compilation (still crashes) for gcc 11.2.0 under Ubnutu 21.10 https://filetransfer.io/data-package/Xp1NUg99#link https://filetransfer.io/data-pac
by LowLevelMahn 4y ago
fixed ONLY the compilation (still crashes) for gcc 11.2.0 under Ubnutu 21.10
https://filetransfer.io/data-package/Xp1NUg99#link https://filetransfer.io/data-package/Xp1NUg99#link
(that should still build/run on your debian 3)
there is a string struct with this inner char s is super-evil
in kernel.h
/\* all strings on the stack will have this format. */
typedef struct {
unsigned int l; /* length of string */
char s; /* string itself \*/
// the rest of the string data
} string;
string get allocated by malloc(sizeof(string)+stringlen+1)
and member char s is then used as the first char + the rest chars from the attached memory
the memory managment is overall a little dirty
and i think it will take some time for a experienced C developer to get that clean and running with todays compiler/checks etc.
- zoomablemind 4y ago>... there is a string struct with this inner char s is super-evil. Apparently, the author wanted to minimize the size of string object by getting rid of the data pointer. Makes sense in general. However, with modern gcc this use triggers secure check to prevent memory overwrites/ string overflow. The check could be disabled/minimized by adding to CFLAGS -Wstringop-overflow=0. Just to prevent it from crashing on this. Also this design could be salvaged by replacing direct references to string->s (string's data pointer) with an inline call to some func: char* c_str(string*) which would return an offseted pointer to the data off string* base pointer. If this is done, then, probably, the stringop-overflow option could be reverted.