Sp.h is the standard library that C deserves

I agree with most of the criticisms they make.

I agree that pointer and length is better than null-terminated strings (although it is difficult in C, and as they mention you will have to use a macro (or some additional functions) to work this in C).

Making the C standard library directly against syscalls is also a good idea, although in some cases you might have an implementation that needs to not do this for some reason, generally it is better for the standard library directly against syscalls.

FILE object is sometimes useful especially if you have functions such as fopencookie and open_memstream; but it might be useful (although probably not with C) to be able to optimize parts of a program that only use a single implementation of the FILE interface (or a subset of its functions, e.g. that does not use seeking).

	▲	fithisux 2 minutes ago \| parent [-]
		Null terminated strings have some merits but they should be a completely different data type like in Freebasic.

▲

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

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

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

	▲	ktpsns an hour ago \| parent [-]
		Exactly. This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big".

▲

Retr0id 2 hours ago | parent | prev | next [-]

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

▲

zamadatix 36 minutes ago | parent | 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 13 minutes ago | parent [-]

What about BSDs?

	▲	whateverboat 6 minutes ago \| parent [-]
		syscalls

▲

Retr0id an hour ago | parent | prev | 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 an hour ago | parent [-]

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

▲

locknitpicker 34 minutes ago | parent | 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 an hour 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 32 minutes ago \| parent [-]
		Commendable accuracy, too: https://godbolt.org/z/s9haz611Y

▲

quuxplusone an hour 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)."

▲

skybrian 2 hours ago | parent | prev | next [-]

My 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?

▲

nektro 36 minutes ago | parent | prev | next [-]

not one mention of Zig on the whole page?

▲

JSR_FDED 44 minutes ago | parent | prev | next [-]

I love how hyper-opinionated this is.

▲

smitty1e 20 minutes ago | parent [-]

Family saying: "It ain't bragging if you can do it."

When one is competent to work at this level, strong opinions are in order.

Their correctness is something I cannot gage. I'm barely competent to follow the conversation.

	▲	rmunn 6 minutes ago \| parent [-]
		Considering the first thing I saw in the thread was https://news.ycombinator.com/item?id=48244891 where the values returned from sp's sine function was compared to the correct values, I'm going to take any such opinions with a few grains of salt. Because the correct sine for the number they tested (31337 radians) is 0.3772 (0.3771522646 according to my calculator), sp's implementation returned 0.4385. That's not even close to right.

▲

Kab1r 2 hours ago | parent | prev | next [-]

Best library name.

▲

TZubiri 2 hours ago | parent | prev [-]

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