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

41–50 of 222 posts

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

#41

Post by bsder »

riedel wrote: post #30
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…

I could not even find a mention what platform it supports. There is a Linux example on the bottom. Have never seem a libc implementation that does not even mention for which platforms it is meant.

You could, of course, spend 30 seconds look at the code on Github which you would have to do if you were interested in using it anyway?

  TRIPLES = \
    x86_64-linux-none x86_64-linux-gnu x86_64-linux-musl \
    aarch64-linux-none aarch64-linux-gnu aarch64-linux-musl \
    aarch64-macos \
    x86_64-windows-gnu \
    wasm32-freestanding wasm32-wasi
Or you could actually try the compliance suite on an architecture and report back to us if it works?

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

#42

Post by gabriela_c »

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

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.

Jesus! Claude could've told this guy all these things. People underestimate how much the average malloc implementation does and how many considerations it makes. Or how much IO sucks.

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

#43

Post by dboon »

nektro wrote: post #13

not one mention of Zig on the whole page?

I had half of a manifesto about how C programmers should be embarrassed on account of Zig but I ended up paring it down to be more focused on what the library is plainly.

Zig is obviously incredible and this library would not exist without it being the standard bearer for systems programming in many ways

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

#44

Post by dboon »

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…

There are very few C libraries which compile, stock, against the matrix of toolchains, ABIs, and operating systems that this library does. For the subset of machines which run, I don't know, 99.9% of all instructions (i.e. x86_64 + aarch64, Linux + Darwin + Windows), the library just works. This is a definition of portability. Why would portability be a binary of supporting every possible system or being hard tied to a single one?

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

#45

Post by HexDecOctBin »

alfiedotwtf wrote: post #35
zzo38computer wrote: post #19

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

Making every C call a system call is not a good idea at all - think about malloc() etc - the OS shouldn’t care about individual allocations and only worry about providing brk() etc. otherwise, performance will die if you’re doing a thousand system calls per second!

No modern libc uses (or should use) brk() as the heap. Allocate virtual memory using mmap, VirtualAlloc, etc., and manage your set of heaps.

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

#48

Post by chrismorgan »

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.

Here’s a diagram that very visibly shows the error: https://www.wolframalpha.com/input?i=plot+y+%3D+sin%28x%29%2...>. And that’s even without accumulated float error if you start outside the range [−π, π] (huge numbers will just be wildly wrong).

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

#49

Post by dboon »

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…

Thanks for reading. "There is no heap" is meant to say that your mental model of memory shouldn't be one heap from which all memory is pulled. It should be many heaps, owned by many different allocators and providing different semantics. Hence the opinionated stance of the library; there is no allocation function that does not force you to specify the specific heap you want to allocate from. I'm sorry if I didn't explain that well.

As far as the syscall thing, it's actually quite interesting. NT is also extremely stable. Likewise for the stock Darwin syscalls on macOS. In practice, though, Windows loads kernel32.dll automatically, so there's no drawback in using it when appropriate. I still call directly into NT sometimes (mostly to skip complex userspace path translations that aren't useful). On macOS, you are likewise forced to link to libc (libSystem.dylib), and so I usually just end up using the syscall-wrapper libc functions there.

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

#50

Post by dboon »

DeathArrow wrote: post #18
zamadatix wrote: post #14

Earlier quoted context omitted.

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

I don't support non-macOS BSDs explicitly yet. Not for any reason of design, just hasn't been a priority.
Post reply on HN