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

81–90 of 222 posts

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

#81

Post by lifthrasiir » 

    Zig, one of the giants upon whose shoulders this library stands, coined a name for this
    almost-but-not-quite-UTF encoding: WTF-8 and WTF-16. These encodings mean, simply, the
    same as their UTF counterpart but allowing unpaired surrogates to pass through.
To give credit where credit is due, both WTF-8 and WTF-16 were devised by Simon Sapin [1] and Zig simply picked them up.

[1] https://wtf-8.codeberg.page/

    sizeof((T){0} = $value)
Wait, is a compound literal an l-value in that sense (as opposed to, just being able to take its reference)?! Take a look at the C99 standard Oh my, it indeed is (C99 §6.5.2.5 p5). Good to know!

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

#82

Post by lifthrasiir »

12_throw_away wrote: post #23
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.

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.

As noted in my other comment though, some interesting decisions and interfaces do point to some degree of human intervention. I have recently written a similarly sized WebAssembly runner in C using agents (feel free to review: [1]) so I'm pretty certain that agents simply don't do that kind of things themselves...

[1] https://github.com/lifthrasiir/wah/

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

#83

Post by hnlmorg »

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

You can be portable, without supporting obscure platforms. Supporting obscure platforms is what makes portability "extreme", though.

“Portable”, in the context of how it was used, generally refers to software using platform agnostic idioms.

If you have to write extensive patches to actually port the software, then it’s only “portable” in the same sense that any software can be ported with enough effort. Ie “Foo is portable. You just have to write a write a whole new kernel to port it”

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

#84

Post by diffuse_l »

boricj wrote: post #37
Sankozi wrote: post #27

Earlier quoted context omitted.

Are there other merits than availability of literals in C? It seems like one of the worst data structures ever - lookup complexity of a linked list with a expansion complexity of an array list with security problems added as a bonus.

It's fine as a serialization/deserialization primitive for on-disk files, as long as the NULL character is invalid. String tables in most object file formats work like that, a concatenated series of ASCIIZ strings. One byte of overhead (NUL), requires only an offset into one to address a string and you can share strings with common suffixes. It's a very compact layout.

Nothing prevents you from using a shared pool of strings that don't have null terminator. It can even be more efficient, since you don't have the null byte to handle at string end. Depending on the maximum string length you want to support, it doesn't even have to take more space.

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

#85

Post by tialaramex »

> I’ve been working on fixing C by giving it a high quality, ultra portable standard library

If the only problem with C was that the stdlib is terrible that would be a very different situation.

There are much more fundamental problems with the language. Problems that are entirely understandable in K&R C but aren't acceptable half a century later. A "high quality" standard library can't fix these problems. In some cases it can paper over them though not others, and even then the actual problem wasn't fixed it's just not obvious with superficial examination any more.

First, the type system is crap. The array types don't work across function boundaries, there's no Empty type at all, you are provided with a user defined product type with names, but not one without names etc. There is no fat pointer type, slice reference, nothing like that.

Second, naming is also crap. There's no namespacing feature provided so you're left with the convention of picking a few letters as a prefix and hoping it doesn't overlap and yet is succinct enough to not be annoying.

Third, everything coerces, all the coercions you could want if you like coercions, and then ten times that many on top. Some people really like coercions, C will see them learn that actually they don't like them that much.

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

#86

Post by af78 »

Sankozi wrote: post #27
fithisux wrote: post #22

Earlier quoted context omitted.

Null terminated strings have some merits but they should be a completely different data type like in Freebasic.

Are there other merits than availability of literals in C? It seems like one of the worst data structures ever - lookup complexity of a linked list with a expansion complexity of an array list with security problems added as a bonus.

One I can think of is simplicity. No need to worry about what the type of the string should be (size_t?) or where it should be stored. Just pass around a pointer. Pointers fit the size of a CPU register most of the time. Though in my opinion the drawbacks (O(N) performance, NUL forbidden etc.) outweigh this benefit we are stuck. Many kernel interfaces like open, getdents etc. assume NUL-terminated strings, therefore any low-level language or library has to support them.

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

#87

Post by teo_zero »

Interesting project! I'm eagerly reading through it.

Probably I would have made different choices. For example, I'd rather have many modules that can be individually included, than one giant file.

Also from a purely aesthetic point of view, I would have opted for more readable function and type names: no sp_ prefix, recognizable names like dict istead of ht, vec instead of da, etc.

And I know there are compilers out there still stuck in the 90s, but I would have targeted C23, these days.

But that would be my highly opinionated library!

P.S. be aware that word frequency is not what the standard 'wc' does.

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

#88

Post by lelanthran »

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

I have no idea what's in the Makefile, and I'm not going to review it just so to try and figure out where a function is defined :-/

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

#89

Post by jamespo »

locknitpicker wrote: post #79
flohofwoe wrote: post #66

Earlier quoted context omitted.

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

Compiling

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

#90

Post by pjmlp »

jamespo wrote: post #89
locknitpicker wrote: post #79

Earlier quoted context omitted.

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

Compiling

Depends how compiling actually happens in practice, what executables and scripts are called.
Post reply on HN