4 ms·
While I'm not entirely sure some of his stuff works correctly, I find that I'm also a fan of getting rid of libc in my code. I already wrote a memcpy, and I alr
by gavinhoward 4y ago
While I'm not entirely sure some of his stuff works correctly, I find that I'm also a fan of getting rid of libc in my code. I already wrote a memcpy, and I already implemented my own buffered I/O. I might as well eliminate everything else that I can.
setjmp and longjmp will have to stay, though.
- stephc_int13 4y agosetjmp and longjmp are very low-level and kind of borderline use-case. I practically almost never use those.
- gavinhoward 4y agoAnd that makes sense. For me, I have a stack allocator that knows about cleaning up, as well as about setjmp and longjmp, so I have a function I can call that will deallocate everything in the stack allocator and do the jump. It's basically a safe exception because everything will be cleaned up properly (if I allocate everything on the stack allocator or be rooted in the stack allocator, which I do).
- marssaxman 4y agoIs this allocator by any chance available online somewhere? I'd like to read and possibly use it.
- gavinhoward 4y agoIt's currently under three licenses to make it as radioactive as possible while the software it supports is under development. Once I'm done, however, it's going to be under a single copyleft license because I never meant it to be incorporated into any code other than my monorepo. It also doesn't even use malloc(), so you wouldn't care about a lot of the details. Links to it are in my comments, but I wouldn't look at it. Instead, I'll describe something you can implement with helps that would be much simpler. Keep a stack of data about allocations. You should keep a pointer to the allocation, the size, and the "destructor" (a function pointer to a function that takes a void pointer and returns nothing). Write 3 destructors. Two should do nothing, but they should be separate. One should be for scopes, and the other should be for functions. The last destructor should cast its void pointer to a jmp_buf pointer and do a longjmp() on it. Then have a normal allocation and deallocation function on the allocator. This is for normal allocations. Have a function to enter a scope, enter a function, and set a jump. In each case, they should push data onto the stack with the appropriate destructor. (I push a pointer to the function name for functions, for debugging.) Then have functions to exit a scope, exit a function, and do a jump. These should "unwind" all allocations until they reach an allocation that uses the scope destructor, function destructor, and setjmp() destructor, respectively. (You can text if two function pointers are equal to each other.) I'll be happy to answer any more questions.
- marssaxman 4y agoThank you for the description.
- flohofwoe 4y agoArguably the mem*() functions are part of the "useful stdlib core" functions. Also be aware that the standard memcpy() and a handful other C stdlib functions are essentially treated like a builtin by compilers, e.g. the compiler can add or remove memcpy calls as it sees fit.
- mgaunard 4y agoThe mem functions are available as compiler built-ins, no need for libc.
- Karellen 4y agoWell, that depends on your compiler.
- mgaunard 4y agoGCC is the standard.
- Karellen 4y agoHuh. Last time I looked at the standard, I didn't see where that was mentioned. Could you point me at the relevant section, please?
- mgaunard 4y agoYou don't appear to understand what the word standard means.
- beached_whale 4y agoIt's called GNU/C Standard /jk
- flohofwoe 4y agoNot on Windows or Mac.
- Asooka 4y agomemcpy is usually treated as an intrinsic and compiled to efficient code when the size is a compile-time constant even in -O0. It is one of the few functions in the standard library that I see as already written to be the best version possible. The one deficiency is that if your ranges overlap, the result is undefined, but you can use memmove instead.
- jenadine 4y agoAnd vice versa. The compiler can detect a loop and replace it by a call to memcpy https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
- CyberDildonics 4y agoThis is actually a big problem and a silly transformation in my opinion. You can write a one line loop that copies memory and suddenly your compiler needs to link with the standard library even if you're trying to avoid it.
- jjnoakes 4y agoYou might want -ffreestanding in those cases.