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

Post by 12_throw_away » Sat, May 23, 2026, 6:13 PM UTC

lifthrasiir wrote: post #82

12_throw_away wrote: post #23

Earlier quoted context omitted.

Oh man. Oof. I'm sure there must be some repository out there that has an AGENTS.md but isn't pure slopcode, but I haven't seen it yet. The number of people who can be trusted to vibe code "responsibly" is probably about the same as the number of people who can be trusted to write memory safe C.

As noted in my other comment though, some interesting decisions and interfaces do point to some degree of human intervention. I have recently written a similarly sized WebAssembly runner in C using agents (feel free to review: [1]) so I'm pretty certain that agents simply don't do that kind of things themselves... [1] https://github.com/lifthrasiir/wah/

Post by 12_throw_away » Sat, May 23, 2026, 6:30 PM 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 Onavo » Sat, May 23, 2026, 6:52 PM UTC

Post by nine_k » Sat, May 23, 2026, 7:29 PM UTC

bryanlarsen wrote: post #111

nextaccountic wrote: post #9

> Principles > Be extremely portable > sp.h is written in C99, and it compiles against any compiler and libc imaginable. It works on Linux, on Windows, on macOS. It works under a WASM host. It works in the browser. It works with MSVC, and MinGW, it works with or without libc, or with weird ones like Cosmopolitan. It works with the big compilers and it works with TCC. > And, best of all, it does all all of that becaus…

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…

Post by dboon » Sat, May 23, 2026, 7:38 PM UTC

bsder wrote: post #103

imtringued wrote: post #100

Earlier quoted context omitted.

You've rejected a user. You can't complain that he has no interest in your project at that point. The bridge is burned.

I don't know how the author would feel. But, honestly, for a libc replacement, I'd personally be okay with that ... If you can't be bothered to look at a Makefile (or ask an AI to look at the Makefile), you are almost certain to be more trouble than any possible benefit you will bring. Especially in the realm of open source, I'm becoming increasingly comfortable with "If you can't be bothered to jump through even the…