sp.h is the standard library that C deserves
16 points by winter
16 points by winter
I would advocate for more readability, especially for a new library. Why all the abbreviations? What is sp_da()? etc.
Author seems pretty high on LLMs and this text reads a bit like it was chewed on by an LLM.
This gives me serious doubt as to whether I should trust that the implementation is written by a real person, too.
I was excited to share with my community, but after the fifth "not X but Y" along with other obvious signs I checked the rest of their website and closed the tab.
It's frustrating, as usual, to find someone cosplaying and wasting our time.
This gives me serious doubt as to whether I should trust that the implementation is written by a real person, too.
sp_sys_sinf(…) looks … odd :) to be quite charitable.
I think "Goals" including "Be extremely portable" conflicts with Non-Goals of "Obscure architectures and OSes". The author's idea of obscure is anything that isn't Windows/MacOS/Linux on x86_64/aarch64, which is telling.
In other words, allocators. They do so by forcing programs to accept that “the ability to allocate any amount of memory from the ether” is not a primitive; it is a fiction. The operating system hands out pages. The runtime on top of it, most often called via malloc(), is what implements the often useful fiction that non-page-sized amounts of memory can be allocated.
But in my experience, that is an unfortunate default rather than something that is true, and this library seeks to make it opt-in rather than opt-out.
Typically, we call these abstraction layers and not "fictions", and most people would agree that allocators are better idea than calling mmap for every allocation, fresh or resizing.
Surely a malloc() style allocator is a better default than that. (Granted, there's also an arena allocator, but even his examples don't seem to use it)
The math library also contains some gems:
f32 sp_sys_sinf(f32 x) {
while (x > 3.14159265f) x -= 6.28318530f;
while (x < -3.14159265f) x += 6.28318530f;
f32 x2 = x * x;
return x * (1.0f - x2/6.0f * (1.0f - x2/20.0f * (1.0f - x2/42.0f)));
}
This will not even terminate for some inputs.
Overall, highly non-serious, for something that calls itself a "high quality, ultra portable standard library" and claims "there is nothing like it.". I would be more charitable if it weren't for the lofty claims and the obvious heavy LLM involvement.
Their approach of effectively making all allocs expensive seem to hit the barrier of giving the user what is essentially decision fatigue, making it also costly to think about.
First example that comes to mind is that your default glibc malloc will arena-alloc for data <= 64 bytes, giving you a big perf boost for a lot of real world string operations, without paying a huge price when going the safe route of just alloc-ing stuff to hand around the program. This library would make you think about it every time while probably gaining you nothing until you hit the point where you will probably start doing real perf measurements anyway.
yes, it's a little concerning that "Be extremely portable" didn't include testing on 32-bit or differently-endian systems. And rolling your own single-precision transcendental functions has never been known to end badly ...
Ignoring the LLM controversy, this project seem to surf the wave of "modernity" without bringing much more thought with it. Nonetheless always nice to see another approach to the design of a general-purpose C library.
I dont think c's issues can be solved with just building a new standard library, ofc libc has its issues, but c has enough issues without it. Maybe filc can solve most issues i have, but i dont think ill ever again choose c for a new project. And i love the minimalism compared to c++ or rust.
I dont think c's issues can be solved with just building a new standard library
That's for sure, but all C problems will not be fixed if libc never changes. That being safety, or ergonomics for example.
This API does look, at a glance, better designed and less footgun prone than libc. libc is a minefield.
I've used libapr once which covers roughly the same ground: libapr is a portable abstraction over OS specific interfaces for files, memory management, sockets and so on. It covers everything you'd need to write something like SVN (which I think libapr was designed for) or Apache httpd. I found libapr nicer than libc. libc's has a very bad error handling situation where every function returns a different sentinel value for errors and libc hides the error codes in a TLS variable called errno. By contrast libapr has uniform error handling: every function returns an error code and other values are returned via pointers. It's still less ergonomic than value and error returns in any of Go, Swift or Rust but it being uniform makes it much nicer than libc. (e.g. a real world example where unix libc having ad-hoc different error sentinel values for every function caused a pretty nasty bug is written up as fork can fail)
I wouldn't use sp.h for one big reason: if I'm going to replace libc then I may as well also jump ship to a better designed language like Zig (if memory unsafety isn't a dealbreaker for me) or one of Go, Swift or Rust (if it is). "C is simple" is not a convincing argument to me because, even though it might be simple itself, C is not simple to use.
This is goofy but I like the ambition of it. Why not reconsider fundamentals of libc like null terminated strings or malloc? Reading this reminded me how different C-the-fancy-assembler is from C-the-platform.
I can't imagine actually using this for much. If I'm going to rewrite the world to a new API I'd probably use Rust or Go to do it. But it's kinda cool to see someone try for C. (And not even C++!)
To my knowledge, [C]'s the only language which: [...]
- Is written in the same language as the OS and most libraries
Indeed. 1 is also the only number equal to 1.
when I clicked on it, my first thought was, "one of the first things had better be a string type that is length and data and all the functions" It is nice to see it there at the top, but now i wonder what else is this thing?