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

71–80 of 222 posts

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

#71

Post by dboon »

Panzerschrek wrote: post #36

How does this library work in programs with parts still requiring libc? How does it deal with code executing before main ? Libc does a bunch of necessary stuff, like calling initializers for global variables.

If your code depends on a bunch of initialization from libc, then you should continue to link to and use libc. sp.h can coexist with libc just fine; if you link to it, the library makes sure to conform where it needs to (e.g. not stomping on the register that holds the TLS base pointer).

What sp.h does not do is reimplement all of libc's initialization code. If you want to build a freestanding binary, there are a few utilities in there for defining a _start so the loader can actually jump to your code. But it's not, and isn't meant to be, a libc replacement in this sense.

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

#72

Post by dboon »

504118318 wrote: post #33

Just taking a quick look at the atomics section: First, (on unix) it's wrapping pthread mutex. That's part of libc! (Technically it might not be libc.so, but it's still the standard library.) Also, none of the atomics talk about the memory model. You don't _have_ to use the C11 memory model (Linux, for example, doesn't). But if you're not using the C11 memory model and letting the compiler insert fences for you, you…

Yes, unfortunately the threading primitives require libc. Ditto subprocesses. It's on my list.

But regarding: "Oops... apparently this is vibecoded. Welp, I just wasted ten minutes of my life reviewing slop that I'm not going to get back."

Do not talk to people like this. I don't care if you don't like the library, or if you found a flaw in it. I am a regular person who wrote this code for no other reason than I thought it would be good to exist. It's unbelievably rude to call it vibecoded slop, or a waste of your life, and it makes me sad that someone who would write an otherwise thoughtful comment would say something like that.

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

#74

Post by dboon »

redlewel wrote: post #28
TZubiri wrote: post #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 cod…

Thanks for this comment, I was about to bookmark the repo for later you saved me the time.

Man, this place has become strange. This person has no idea who I am. But thanks for commenting on my 'library' nonetheless!

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

#75

Post by dboon »

flohofwoe wrote: post #66
lelanthran wrote: post #52

Earlier quoted context omitted.

> This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big". The number might just be zero - did anyone check if this compiles? I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined (used in 3x places) but it doesn't appear in the GH search results. I'm not going to clone and build this (too dangerous).

> I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined A quick glance at the source on github and here you go: https://github.com/tspader/sp/blob/e64697aa649907ce3357a7dd0... `sp_mem_allocator_alloc_type ` is going through a couple of macro resolutions which ends up at `sp_mem_allocator_alloc` > I'm not going to clone and build this (too dangerous). Your computer won't explode just fr…

It looks like I need to update my macOS machine! Thanks for the sanity, and thanks for reading.

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

#76

Post by dboon »

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.

It...is not a libc implementation. That's an impressive level of misunderstanding!

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

#77

Post by flohofwoe »

Panzerschrek wrote: post #32

It's a disadvantage, that it's header-only. It needs to include and a bunch of other stuff, which slow-downs compilation. Splitting it into a couple of files (a header and an implementation) would be much better.

This normally isn't a problem since windows.h and other big system headers are usually only needed in the implementation part, not in the declaration part of the header (this is an STB-style header where the implementation is isolated in an `#ifdef IMPL` section).

Unfortunately though this particular header seems to include the system headers up in the declaration part of the header.

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

#79

Post by locknitpicker »

flohofwoe wrote: post #66
lelanthran wrote: post #52

Earlier quoted context omitted.

> This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big". The number might just be zero - did anyone check if this compiles? I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined (used in 3x places) but it doesn't appear in the GH search results. I'm not going to clone and build this (too dangerous).

> I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined A quick glance at the source on github and here you go: https://github.com/tspader/sp/blob/e64697aa649907ce3357a7dd0... `sp_mem_allocator_alloc_type ` is going through a couple of macro resolutions which ends up at `sp_mem_allocator_alloc` > I'm not going to clone and build this (too dangerous). Your computer won't explode just fr…

> Your computer won't explode just from downloading and compiling some C code, don't worry ;)

This is the first time I ever saw anyone dismissing the risk of downloading and running stuff off the internet.

"Don't worry".

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

#80

Post by p4bl0 »

First, thanks for sharing this link, it was an interesting read! A few remarks below.

I had a hard time reading the wc code in the article. First I had to go to the GitHub to understand that "da" stands for dynamic array, and then understand that what the author calls wc is not at all the wc linux commands, which by default gives you the number of lines, words, and characters in a file, not the count of occurrences of each word in the file, which is what the proposed code does.

Also, since I had to read the GitHub README, another remark: it says that sp_io uses pthreads rather than fork and exec. Both of those approach (but especially pthreads) are contradictory to the explicit goals of programming against lowest level interfaces. I believe the lowest level syscall is clone3 [1], which gives you more fine grained control on what is shared between the parent and child processes, allowing to implement fork or threads.

[1] https://manpages.debian.org/trixie/manpages-dev/clone3.2.en....

Post reply on HN