3 ms·

libc's been poisoning software long enough. Glad it's optional in Zig on platforms that provide stable system ABI.

• quotemstr 1y ago
  "[P]oisoning"? Do you have a technical objection, or do you just not like the letter "c"?
  • throwA29B 1y ago
    libc, starting with errno, continuing with fopen/printf/str* functions, locales, etc is a pile of quick hacks; set of useful abstractions at the time, no doubt! But that time is long gone, for decade(s) it is nothing but a drag.
  • Cloudef 1y ago
    libc carries lots of global state and implicit ABI that complicates software stacks. While I don't like dynamic libraries in general, dynamic libraries wouldn't be such a mess as they are if libc did not exist. I dream of day we can actually do GPU rendering on linux without libc, and have actual static binaries for graphical apps that work everywhere.
    • quotemstr 1y ago
      That global state is the coordination problem it's solving. Who owns the thread list? The current process wide setreuid identity? The loaded library list? Debug info registrations? Shared dynamic memory allocations? TLS slots? Someone has to, and that someone is libc. Avoiding it because it has state is to be confused about the whole concept of an OS. Yeah, it's mixed up with the same library that provides sscanf and strcat. So what? You don't have to call them.