sp.h: Fixing C by giving it a high quality, ultra portable standard library

Post by rixed » Sun, May 24, 2026, 4:13 AM UTC

dboon wrote: post #72

504118318 wrote: post #33

Just taking a quick look at the atomics section: First, (on unix) it's wrapping pthread mutex. That's part of libc! (Technically it might not be libc.so, but it's still the standard library.) Also, none of the atomics talk about the memory model. You don't _have_ to use the C11 memory model (Linux, for example, doesn't). But if you're not using the C11 memory model and letting the compiler insert fences for you, you…

Yes, unfortunately the threading primitives require libc. Ditto subprocesses. It's on my list. But regarding: "Oops... apparently this is vibecoded. Welp, I just wasted ten minutes of my life reviewing slop that I'm not going to get back." Do not talk to people like this. I don't care if you don't like the library, or if you found a flaw in it. I am a regular person who wrote this code for no other reason than I thou…

Post by gritzko » Sun, May 24, 2026, 4:32 AM UTC

ndesaulniers wrote: post #183

I spent a bit of time implementing parts of a C runtime for the brief tenure I had maintaining LLVM's libc. I quickly came the realization that a lot of the interfaces that made it all the way to standardization were trash. How the language is standardized is still comical to me. I agree with TFA that C style strings are trash.

Post by magicalhippo » Sun, May 24, 2026, 5:36 AM UTC

nine_k wrote: post #137

bryanlarsen wrote: post #111

Earlier quoted context omitted.

It's an odd stance for a C library. In my experience, odd platforms are the main place that C is used in 2026. If you're writing a new Windows or Linux or MacOS or WASM program, it's not likely to be in C. But lots of new microcontroller software is still being written in C. And he's already hit the hard targets. Many obscure OS's are generally UNIX like and should be easy ports. Many obscure arch's usually are runni…

Aren't these MCUs predominantly ARM-based, with some RISC-V thrown in? I see no contradiction in the desire to support x64 (because it would be ridiculous not to), ARM, and likely RISC-V, but not the venerable but now-fringe architectures like MIPS or Sparc or 68040 or even x86.

Post by WalterBright » Sun, May 24, 2026, 6:12 AM UTC

gritzko wrote: post #191

WalterBright wrote: post #138

https://spader.zone/sp/#null-terminated-strings-are-the-devi... Pointer/length is not just for strings - but for all arrays. See my proposal: https://www.digitalmars.com/articles/C-biggest-mistake.html

I use a C dialect with (ptr,ptr) slices and (ptr,ptr,ptr,ptr) buffers. Effectively a different programming language, still uses standard C compiler. https://github.com/gritzko/libabc In this day and age, the top problem is Claude bringing lots and lots of bad C into the code base. Takes a weekend to clear the week's mess. https://github.com/gritzko/beagle In a cleared codebase though all the usual C memory bugs are v…

Post by p4bl0 » Sun, May 24, 2026, 6:45 AM UTC

fc417fc802 wrote: post #166

p4bl0 wrote: post #80

First, thanks for sharing this link, it was an interesting read! A few remarks below. I had a hard time reading the wc code in the article. First I had to go to the GitHub to understand that "da" stands for dynamic array, and then understand that what the author calls wc is not at all the wc linux commands, which by default gives you the number of lines, words, and characters in a file, not the count of occurrences o…

To be portable it's probably best to use the pthreads API for everything, make no additional assumptions, and rely on the user to provide the implementation. Consider what happens when someone is working with OpenMP, CUDA, or similar and attempts to make use of a dependency that in turn makes use of your library. The easier it is to understand the assumptions made by your library the better.