actually, first a short rant
i hate the libc
even outside the fact it's 99% antiquated nonsense you should never use,
a lot of it (integer types, stdarg, math functions, string/memory operations) should be handled by the compiler instead of the libc - in fact, most of the time libcs do these by just stubbing compiler intrinsics, which bruh
then stuff like memory allocation, file management, and really most IO-adjacent operations are really application/system-specific and should be put in a separate library instead of the libc proper
now you might say, wait then what would remain in the libc
exactly
i hate the libc
even outside the fact it's 99% antiquated nonsense you should never use,
a lot of it (integer types, stdarg, math functions, string/memory operations) should be handled by the compiler instead of the libc - in fact, most of the time libcs do these by just stubbing compiler intrinsics, which bruh
then stuff like memory allocation, file management, and really most IO-adjacent operations are really application/system-specific and should be put in a separate library instead of the libc proper
now you might say, wait then what would remain in the libc
exactly
Good take.
I'd phrase it differently, e.g. I don't think the compiler should do much more (integer types ok, stdarg maybe, everything else nah), but a lot of the stuff can go into external libraries.
@niplav the stuff i listed as should be in the compiler are all heavily arch-dependent. the compiler does arch-dependent stuff, that's its job
@niplav i mean, to be performant you're gonna want to exploit scheduling and wide moves as much as possible, that's inherently arch-dependent. there's a reason this stuff is typically written in assembly
