sp.h: Fixing C by giving it a high quality, ultra portable standard library
1–10 of 222 posts
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#2> Every language that depends on third party libraries, like js and python, is getting massively infected with supply chain worms
> Only couple of languages not affected are those that don't have a culture of downloading third party code, like C and C++
> Ex js and python developer publishes a 'library'
> Library is vibe coded
> Published on github amidst GitHub being hit by supply chain attacks, had their source code leaked.
The timing is terrible for starters, and I don't trust the vibe coded code at all. Imagine a pandemic and the cities are on fire, and you arrive to a rural town asking to kiss people.
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#3My impression of the sample programs is that they're unreadably noisy, but maybe this would be a good compiler target if you're writing your own language?
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#4> Program directly against syscalls
Works nicely on Linux where the syscall interface is explicitly stable, but on many (most?) other platforms this is not the case.
> There Is No Heap
I don't understand what this means, when it's followed by the definition of a heap allocation interface. The paragraph after the code block conveys no useful information.
> Null-terminated strings are the devil’s work
Agreed! I also find the stance regarding perf optimization agreeable.
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#5Best library name.
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#6> Program directly against syscalls Works nicely on Linux where the syscall interface is explicitly stable, but on many (most?) other platforms this is not the case. > There Is No Heap I don't understand what this means, when it's followed by the definition of a heap allocation interface. The paragraph after the code block conveys no useful information. > Null-terminated strings are the devil’s work Agreed! I also fi…
The "definition of a heap allocation interface" indicates that there is no standard heap. Instead, there's a standard interface for the use to define their own heaps. Any standard library function that needs to allocate will take a sp_allocator_t parameter, and use that to allocate. As opposed to e.g. strdup, which hard-codes a call to malloc internally. Sp.h's strdup-alike would take an sp_allocator_t as input and call into that to get the memory it needs.
A C++ programmer might describe this as "PMR, but not default-constructible. And std::stable_sort takes a PMR allocator parameter. And PMR is the default, and there's no implementation of std::allocator (or new or delete)."
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#7> Program directly against syscalls Works nicely on Linux where the syscall interface is explicitly stable, but on many (most?) other platforms this is not the case. > There Is No Heap I don't understand what this means, when it's followed by the definition of a heap allocation interface. The paragraph after the code block conveys no useful information. > Null-terminated strings are the devil’s work Agreed! I also fi…
Looks like the default allocator uses mmap(2) for every single allocation, which is horribly inefficient - you map a whole PAGE_SIZE worth of memory for every tiny string. Aside from just wasting memory this will make the TLB very unhappy.
It looks like sp_log's string formatting is entirely unbuffered which results in lots of tiny write syscalls.
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#8> Program directly against syscalls Works nicely on Linux where the syscall interface is explicitly stable, but on many (most?) other platforms this is not the case. > There Is No Heap I don't understand what this means, when it's followed by the definition of a heap allocation interface. The paragraph after the code block conveys no useful information. > Null-terminated strings are the devil’s work Agreed! I also fi…
Looks like the default allocator uses mmap(2) for every single allocation , which is horribly inefficient - you map a whole PAGE_SIZE worth of memory for every tiny string. Aside from just wasting memory this will make the TLB very unhappy. It looks like sp_log's string formatting is entirely unbuffered which results in lots of tiny write syscalls.
That seems to be a pretty consistent quality level for the entire library. Look at the implementations in sp_math, yikes.
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#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 because it’s small, not because it’s big.
vs
> Non-goals
> Obscure architectures and OSes
> I write code for x86_64 and aarch64. WASM is becoming more important, but is still secondary to native targets. I don’t care to bloat the library to support a tiny fraction of use cases.
> That being said, if you’re interested in using the library on an unsupported platform, I’m more than happy to help, and if we can make the patch reasonable, to merge it.
Those are contradictory. Either the code is extremely portable, or it can't support "obscure" platforms, but not both.
Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library
#10Earlier quoted context omitted.
Looks like the default allocator uses mmap(2) for every single allocation , which is horribly inefficient - you map a whole PAGE_SIZE worth of memory for every tiny string. Aside from just wasting memory this will make the TLB very unhappy. It looks like sp_log's string formatting is entirely unbuffered which results in lots of tiny write syscalls.
That seems to be a pretty consistent quality level for the entire library. Look at the implementations in sp_math, yikes.
"How bad can it be, I mean I know that numerics are not many people's strong suit, but..."
... ... ... oh wow, the math functions are really bad implementations. The range reduction on the sin/cos functions are yikes-level. Like the wrong input gives you an infinite loop level of yikes.