[dboon]

There are very few C libraries which compile, stock, against the matrix of toolchains, ABIs, and operating systems that this library does. For the subset of machines which run, I don't know, 99.9% of all instructions (i.e. x86_64 + aarch64, Linux + Darwin + Windows), the library just works. This is a definition of portability. Why would portability be a binary of supporting every possible system or being hard tied to a single one?

[taneq]

This debate reminds me of way back in the day when Java first became popular. I excitedly started writing things in Java because it would be portable! I quickly learned, of course, that Java was not portable at all, for values of ‘portable’ equal to ‘my friends can run it without installing the JRE and using the command line’, which is the actual definition in practice. Those friends all ran Wintel boxes. A Win32 i386 binary was (and probably still is) the most universally runnable native code.

[AlotOfReading]

The natural comparisons are libraries like glibc and newlib, which do support lots of architectures and more importantly make porting to new architectures or taking advantage of platform features pretty straightforward.

[trueno]

people also greatly underestimate the performance of glibc and the insane work and literal decades it's taken to achieve. people keep relearning this lesson the hard way when they link musl and suffer perf issues. one needs not look further than the libc mailing lists and if they were so dedicated could probably find a discussion on every performance issue they face with the glibc alternatives over the decades.

for embedded defs not against portable alternatives like this tho.

however ops post sure gets off on the wrong foot by saying this is "fixing C". the hubris of mankind on full display, yet again

[scott01]

I’m not as experienced as some people here, but in ~10 years, I’ve never needed to write code for anything other than x86 or arm. So I agree with the author on their priorities.

[hnlmorg]

Not all ARM systems are created equally. For example many of the 32bit ARM processor didn’t even support floating point ops. So they’d have to be calculated in software.

Aside from various different variations of ARM, I’ve worked several variations of x86 and AMD64, SPARC, PowerPC, MIPS and others I’ve likely forgotten. Not to mention a few 8-bit CPUs too, but those there more than 20 years ago and not really fair to discuss here.

[sitzkrieg]

in just the past ten years i’ve had to write asm for x86, arm, mips, riscv, 8051 and something else i can’t even remember. generalizing rules