Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

spader.zone

Post reply on HN
Print view View original

11–20 of 222 posts

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

#11

Post by ktpsns »

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…

Exactly. This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big".

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

#14

Post by zamadatix »

Retr0id wrote: post #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 fi…

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

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

#15

Post by locknitpicker »

AlotOfReading wrote: post #8
Retr0id wrote: post #7

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

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

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

#16

Post by lacewing »

jcranmer wrote: post #10
AlotOfReading wrote: post #8

Earlier quoted context omitted.

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.

Commendable accuracy, too: https://godbolt.org/z/s9haz611Y

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

#17

Post by smitty1e »

JSR_FDED wrote: post #12

I love how hyper-opinionated this is.

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.

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

#18

Post by DeathArrow »

zamadatix wrote: post #14
Retr0id wrote: post #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 fi…

> 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 q…

What about BSDs?

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

#19

Post by zzo38computer »

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

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

#20

Post by rmunn »

smitty1e wrote: post #17
JSR_FDED wrote: post #12

I love how hyper-opinionated this is.

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.

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.
Post reply on HN