> 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.

▲

Retr0id 2 hours ago | parent | next [-]

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.

▲

AlotOfReading 2 hours ago | parent [-]

That seems to be a pretty consistent quality level for the entire library. Look at the implementations in sp_math, yikes.

▲

12_throw_away 40 minutes ago | parent | next [-]

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.

▲

locknitpicker an hour ago | parent | prev | next [-]

> That seems to be a pretty consistent quality level for the entire library. Look at the implementations in sp_math, yikes.

That does spin the meaning of "Sp.h is the standard library that C deserves"

▲

jcranmer 2 hours ago | parent | prev [-]

"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.

	▲	lacewing an hour ago \| parent [-]
		Commendable accuracy, too: https://godbolt.org/z/s9haz611Y

▲

zamadatix an hour ago | parent | prev | next [-]

> Works nicely on Linux where the syscall interface is explicitly stable, but on many (most?) other platforms this is not the case.

There is a footnote on this saying as much:

> 3. Where “syscall” means “the lowest level primitive available”. On Linux, it’s always actual syscalls. On Windows, that’s usually NT. On macOS, it’s usually the syscall-wrapper subset of libc because you’re forced to link libc and it’s not quite as open as Linux (although there is a rich “undocumented” set of APIs and syscalls that are very interesting).

▲

DeathArrow an hour ago | parent [-]

What about BSDs?

	▲	whateverboat an hour ago \| parent [-]
		syscalls

▲

quuxplusone 2 hours ago | parent | prev [-]

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)."