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

111–120 of 222 posts

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

#111

Post by bryanlarsen »

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…

It's an odd stance for a C library. In my experience, odd platforms are the main place that C is used in 2026. If you're writing a new Windows or Linux or MacOS or WASM program, it's not likely to be in C. But lots of new microcontroller software is still being written in C.

And he's already hit the hard targets. Many obscure OS's are generally UNIX like and should be easy ports. Many obscure arch's usually are running Linux and should be easy ports.

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

#113

Post by rigonkulous »

lelanthran wrote: post #52
ktpsns wrote: post #11

Earlier quoted context omitted.

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

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

For C-based projects, use cscope. It found it pretty fast.

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

#114

Post by rigonkulous »

lelanthran wrote: post #88
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 ;) 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 :-/

Use better tooling, then. Cscope is your friend.

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

#115

Post by taneq »

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

This debate reminds me of way back in the day when Java first became popular. I excitedly started writing things in Java because it would be portable! I quickly learned, of course, that Java was not portable at all, for values of ‘portable’ equal to ‘my friends can run it without installing the JRE and using the command line’, which is the actual definition in practice. Those friends all ran Wintel boxes. A Win32 i386 binary was (and probably still is) the most universally runnable native code.

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

#116

Post by king_geedorah »

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…

Portability across compilers is orthogonal to portability across target architectures.

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

#117

Post by tialaramex »

flohofwoe wrote: post #97
tialaramex wrote: post #85

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

These are all just your personal preferences. Just use another language instead which better matches your taste, nobody forces you to use C and there are plenty of more opinionated alternatives. FWIW, the standard library being stuck in the K&R era is an actual problem since it doesn't make use of more modern language features and some functions are downright footgun magnets, but nobody quite agrees what a modern std…

Nah, I spent many years writing C for a living. That library isn't from the K&R era, it's from C89, the problems I'm talking about are much more fundamental.

Of course nobody forces me to use C, which is why I stopped writing C a few years ago.

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

#118

Post by voakbasda »

feelamee wrote: post #105
dboon wrote: post #56

Earlier quoted context omitted.

The point of the library is that you do not call the low level allocation primitive to allocate a single string. Of course, in simple programs which exit immediately, there is no difference between using a page allocator and a heap allocator. In real programs, I use an appropriate allocator for the allocation rather than making arbitrary calls to malloc(). In the sp.h examples, I use the page allocator to keep freest…

q> sp_log() writes directly to an IO writer. An IO writer can be buffered or unbuffered, but is unbuffered by default. This is a feature, not a bug. Have a look through the IO code! Why is the unbuffered default? Is there any thoughts on this?

A buffered file may not be fully written to disk if the program exits suddenly. That’s generally a highly undesirable trait for a log file.

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

#119

Post by ozgrakkurt »

pjmlp wrote: post #29

We should have left C in the 90's already, but then FOSS happened, "Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C." The GNU Coding Standard in 1994, http://web.mit.edu/gnu/doc/html/sta…

C is the only language I found where it is possible to isolate yourself from the "AMAZING" ideas of programming language creators.

There is no language other than C and C++ that is mature enough that you can actually discard the implicit runtime stuff and still be able to code in the language. C++ is too complex in my opinion so I only get to use C as a minimal language.

Even if you look at a language like Zig. You have implicit error trace printing stuff that is inaccurate when using optimized builds, you get a very bad fuzz implementation that doesn't work properly, you get comptime reflection which will be insane in the hands of the people that are writing rust now. Also a bunch of features you would want to use to discard the runtime are not documented/stable.

You can't even use Odin without libc as far as I can understand.

Hare doesn't even have inline asm.

Contrast with using C with clang/gcc where you can do '-nostdinc' '-nostdlib', then implement memcpy etc. and you can do w/e you want after that.

Rust as a nother example is trash for doing low level projects without pulling the 10billion lines of code that comes with using rust like libc/stdlib/binding libaries etc. etc.

You can use libraries that other people built in Rust but doing it yourself takes much more time than doing it in a language like C or Zig.

Another thing is, C is easy to implement. Implementing Rust/C++/Zig or any of the other languages is basically impossible in comparison.

Also I found that C is the only language that you can go into a very big project and open a random file and roughly understand what is going on. This is not possible in any of these other laguages other than Zig and I suspect it will get very bad in Zig when(if) the lower skill level people that are currently writing Rust start moving to writing Zig.

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

#120

Post by 504118318 »

dboon wrote: post #72
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 thou…

You're absolutely right. I should have expressed my late-night frustration more kindly.
Post reply on HN