5/23/2026 at 4:44:44 AM
> 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 because it’s small, not because it’s big.
vs
> Non-goals
> Obscure architectures and OSes
> I write code for x86_64 and aarch64. WASM is becoming more important, but is still secondary to native targets. I don’t care to bloat the library to support a tiny fraction of use cases.
> That being said, if you’re interested in using the library on an unsupported platform, I’m more than happy to help, and if we can make the patch reasonable, to merge it.
Those are contradictory. Either the code is extremely portable, or it can't support "obscure" platforms, but not both.
by nextaccountic
5/23/2026 at 12:02:00 PM
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.
by bryanlarsen
5/23/2026 at 7:43:07 PM
I have no philosophical complaints with supporting odd architectures in general. I agree that most obscure targets are probably not that much code, since the library is factored with this in mind (e.g. basic WASM support took an afternoon).It's stated as a non-goal simply because it's not the most valuable thing I can do with my time. My fundamental stance is that writing new Windows or Linux or macOS or WASM programs in C is a good idea, and those are the programs that I write, so that's where my focus is. But if someone would like to come along and write the ~30 syscalls needed to port the library to a new platform, or even register any interest in such, I'd be happy to look into it at that point.
by dboon
5/23/2026 at 9:57:59 PM
That's fine. Just don't call it "ultra portable" while treating it as a non-goal.by yjftsjthsd-h
5/24/2026 at 12:13:44 PM
He's already hit the hard targets. I think ultra portable is an accurate description. Portable means able to be ported, not "has been ported".by bryanlarsen
5/24/2026 at 4:33:11 PM
Like. He's done the first 90%, leaving only the other 90%. And I mean that a little as a joke but also very sincerely. The supported platforms are a decent starting point, but mainstream OSs on little-endian 64-bit processors doesn't strike me as "the hard targets". NetBSD ( https://wiki.netbsd.org/ports/ ) is ultra portable. This is just portable.by yjftsjthsd-h
5/24/2026 at 2:37:50 AM
I'm seeing that people have a big issue with the language, but "ultra" doesn't even necessarily mean "total"by rTX5CMRXIfFG
5/24/2026 at 6:55:47 AM
Ultra might be a step below total, but the 3 most common OSs on the 2 most common ISAs is ... several steps below ultra.by yjftsjthsd-h
5/23/2026 at 7:29:59 PM
Aren't these MCUs predominantly ARM-based, with some RISC-V thrown in?I see no contradiction in the desire to support x64 (because it would be ridiculous not to), ARM, and likely RISC-V, but not the venerable but now-fringe architectures like MIPS or Sparc or 68040 or even x86.
by nine_k
5/23/2026 at 10:51:26 PM
The author can do whatever they want. But if all you want to support is x86-64, ARM64 and maybe some version of RISC-V, don't crow about how 'extremely' portable you are. At best, you don't know.by kjs3
5/24/2026 at 12:22:52 AM
portable is a different word from ported.by Brian_K_White
5/24/2026 at 6:50:53 PM
Yes, my grasp of english is adequate to understand these words. I just think it's a huge stretch of hubris to claim something is 'portable', especially to claim it's "ultra" portable, if you've not done the actual work to port it or only ported it once. For example, people have learned an awful lot about real world memory alignment issues by actually porting something to SPARC. The author is guessing at best.But yeah...for some people "meh, close enough" is good enough.
by kjs3
5/24/2026 at 12:30:20 AM
>now-fringe architectures like MIPSFor those not in the know, Microchip still produces MIPS microcontrollers:
https://www.microchip.com/en-us/products/microcontrollers/32...
by floxy
5/24/2026 at 5:36:45 AM
AfAIK lots of 8051-based microcontrollers that are quite modern, such as Silicon Labs EFM8 line[1] or STC which in addition to 8-bit 8051's also has 32-bit 8051 variants[2].by magicalhippo
5/23/2026 at 1:27:02 PM
Portability across compilers is orthogonal to portability across target architectures.by king_geedorah
5/24/2026 at 4:16:53 AM
This is true, but it would probably be good to be specific what is meant by "portable". There is also the dimension of operating system.It sounds like it has a goal of being "extremely portable" across compilers, (although I'm curious how many compulers it is actually tested against) but only somewhat portable across architectures and operatings systems, just hitting the most popular ones.
by thayne
5/24/2026 at 12:22:07 PM
The section with heading "Be Extremely Portable" seems relatively clear to me, but perhaps that is just because I already understand host vs target compatibility.by king_geedorah
5/23/2026 at 6:22:59 AM
You can be portable, without supporting obscure platforms.Supporting obscure platforms is what makes portability "extreme", though.
by kazinator
5/23/2026 at 8:05:05 AM
“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”
by hnlmorg
5/23/2026 at 2:54:31 PM
Is the Foo kernel 75% of the code base, 5% or 0.01%?by kazinator
5/23/2026 at 9:46:24 PM
I’m not getting dragged into a strawman argument about meaningless hypothetical percentages of a vague and arbitrary illustration. And particularly not when the point being made was pretty clear:> “Portable”, in the context of how it was used, generally refers to software using platform agnostic idioms.
by hnlmorg
5/23/2026 at 11:23:27 PM
Portable has two meanings: a construct is portable if we can rely on it to work everywhere. A portable codebase is one that supports moving to a new platform, with some nonzero effort which is not large compared to rewriting the code. It is able to be ported. E.g, "Johnson's Portable C Compiler (PCC)".If only the Foo kernel must be rewritten in order to port Foo, but that kernel is 75% of Foo, then I would say Foo is not portable. If the kernel is 0.1% of Foo, then I would say that it is: 99.9% of the code base depends on the abstractions in the Foo kernel rather than platform features.
by kazinator
5/24/2026 at 8:16:49 AM
> “Portable”, in the context of how it was used, generally refers to software using platform agnostic idioms.“in the context of how it was used,”
This isn’t some meta conversation about how to write portable software. This is a conversation specific to what the author had written about their project.
by hnlmorg
5/24/2026 at 5:14:50 PM
In context, they probably mean portable by installed base of targets. In a world in which nothing but ARM cores exist, a machine language ARM program is portable, and even "extremely" so.There is a usage of "portable" which has to do with percentage of installations it runs in or can be easily made to run in, regardless of how much has to be changed to get it working anywhere else.
by kazinator
5/25/2026 at 2:53:20 PM
You are using the term incorrectly.As I said before:
> “Portable”, in the context of how it was used, generally refers to software using platform agnostic idioms.
Words have meanings. If the code is tied to an architecture then it isnt portable. And as you said, there’s nothing wrong with that. But arguing some other definition of a word people are already using is just stupid.
by hnlmorg
5/23/2026 at 9:14:09 AM
Yeah he doesn't even try to support major platforms like RISC-V. I know there is fragmentation, but best effort attempts at portability would show some sign of goodwill.by imtringued
5/23/2026 at 10:41:45 PM
> Those are contradictory. Either the code is extremely portable, or it can't support "obscure" platforms, but not both.I think it's perfectly valid to call code 'extremely portable' without supporting every special snowflake architecture. There's a spectrum from assumptions that hold on everything that isn't some esoteric joke architecture or archaeology to something that I would probably consider required for 'extremely portable'.
I would personally consider something that failed to support anything on this list above big endian as still being extremely portable: you'll build for any serious modern architecture that isn't a DSP.
- non twos complement integers
- (int) nullptr != 0
- segmented addressing
- non-8 bit char
- big endian
- missing floating point
ARM's done a good job of making it so that you can't assume the traditional x86 assumptions of being able to access any pointer unaligned or having sequentially consistent semantics on memory ordering (with the help of compilers getting better at reordering resulting in you needing to have proper semantics on x86 as well).
by murderfs
5/23/2026 at 11:04:15 PM
It makes liberal use of u64 all over the place rather than a more appropriate, machine adaptive unsigned int or unsigned long. It isn't a good fit for anything "exotic" like non-64-bit platforms. I wouldn't consider that in the spirit of portability when it compiles into bloated code with unnecessarily large structs.by kevin_thibedeau
5/24/2026 at 12:34:06 AM
I was making a general point about portability, not this library in particular. I wouldn't consider "only x86_64 and aarch64" as being "portable".by murderfs
5/23/2026 at 4:50:19 AM
Exactly. This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big".by ktpsns
5/23/2026 at 5:47:10 AM
We support extreme portability for sufficiently large values of two.by noosphr
5/23/2026 at 8:59:03 PM
When I was a wee lad, a conference speaker announced that "portability" meant "runs on anything that supports OS/360".by egl2020
5/23/2026 at 6:55:33 AM
> 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).
by lelanthran
5/23/2026 at 7:16:08 AM
> I am trying to track down where the function `sp_mem_allocator_alloc_type` is definedA 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 from downloading and compiling some C code, don't worry ;)
The github repo builds and the examples run just fine on macOS by just running `make` in the project directory, although with one warning:
warning: 'posix_spawn_file_actions_addchdir_np' is deprecated: first deprecated in macOS 26.0
by flohofwoe
5/23/2026 at 7:35:43 AM
It looks like I need to update my macOS machine! Thanks for the sanity, and thanks for reading.by dboon
5/23/2026 at 10:03:07 AM
Only if you want to move from MacOS Sequoia to Tahoe. Tahoe has the Liquid Glass stuff that people don't like as well as other UX changes that have been controversial.Apple still do security updates on Sequoia.
by rswail
5/23/2026 at 7:46:03 AM
> 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".
by locknitpicker
5/23/2026 at 8:22:23 AM
Compilingby jamespo
5/23/2026 at 8:42:32 AM
Depends how compiling actually happens in practice, what executables and scripts are called.by pjmlp
5/23/2026 at 11:01:54 AM
"I have no idea how that rm -rf $HOME ended up in the Makefile"by lmz
5/23/2026 at 8:44:13 AM
Did you never install anything on your computing device? It's the same risk, or even worse if it was closed source software installed via an app storeby flohofwoe
5/24/2026 at 12:01:03 PM
I'm trying to sort out the whole mess of sp_ht / sp_str_ht_init / sp_str_split_c8 / sp_da_for / sp_da. sp_da_fuq? What is all this stuff?by pseudohadamard
5/23/2026 at 8:21:05 AM
> 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 :-/
by lelanthran
5/23/2026 at 8:47:33 AM
I found the function body in about 30 seconds by browsing the code on github via plain old text search. Is that also to dangerous? ;)by flohofwoe
5/23/2026 at 1:15:58 PM
Use better tooling, then. Cscope is your friend.by rigonkulous
5/23/2026 at 9:37:31 AM
> I'm not going to clone and build this (too dangerous).Just create a disposable isolated environment, like VM or container, and do it inside? And, yes, does compile.
by forgotpwd16
5/23/2026 at 1:15:14 PM
For C-based projects, use cscope. It found it pretty fast.by rigonkulous
5/23/2026 at 6:42:08 AM
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?by dboon
5/23/2026 at 1:26:50 PM
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.by taneq
5/23/2026 at 6:57:49 AM
The natural comparisons are libraries like glibc and newlib, which do support lots of architectures and more importantly make porting to new architectures or taking advantage of platform features pretty straightforward.by AlotOfReading
5/24/2026 at 4:00:51 AM
people also greatly underestimate the performance of glibc and the insane work and literal decades it's taken to achieve. people keep relearning this lesson the hard way when they link musl and suffer perf issues. one needs not look further than the libc mailing lists and if they were so dedicated could probably find a discussion on every performance issue they face with the glibc alternatives over the decades.for embedded defs not against portable alternatives like this tho.
however ops post sure gets off on the wrong foot by saying this is "fixing C". the hubris of mankind on full display, yet again
by trueno
5/23/2026 at 7:10:08 AM
I’m not as experienced as some people here, but in ~10 years, I’ve never needed to write code for anything other than x86 or arm. So I agree with the author on their priorities.by scott01
5/23/2026 at 9:13:54 AM
Not all ARM systems are created equally. For example many of the 32bit ARM processor didn’t even support floating point ops. So they’d have to be calculated in software.Aside from various different variations of ARM, I’ve worked several variations of x86 and AMD64, SPARC, PowerPC, MIPS and others I’ve likely forgotten. Not to mention a few 8-bit CPUs too, but those there more than 20 years ago and not really fair to discuss here.
by hnlmorg
5/23/2026 at 6:52:06 PM
in just the past ten years i’ve had to write asm for x86, arm, mips, riscv, 8051 and something else i can’t even remember. generalizing rulesby sitzkrieg
5/23/2026 at 6:24:50 AM
That’s a lot of text to say “well ackshually”.by forrestthewoods
5/23/2026 at 6:00:24 AM
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.by riedel
5/23/2026 at 6:25:37 AM
> 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.by forrestthewoods
5/23/2026 at 7:37:20 AM
It...is not a libc implementation. That's an impressive level of misunderstanding!by dboon
5/24/2026 at 6:21:49 PM
The title says 'standard library'. Are you saying that, in the context of C, that it is an error to take that to mean an implementation of libc?Yes, I know the author's writeup then goes on to say that it is not a libc with a pile of questionable justfication. This is a custom runtime, in a single header no less, which is admittedly impressive, especially considering it provides runtime and thread safety primitives. This does not rise to the level of claiming the idea of a 'standard libarary' though, IMO. In that, I think the author misses the point.
by vetrom
5/23/2026 at 6:28:06 AM
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?
by bsder
5/23/2026 at 9:17:25 AM
You've rejected a user. You can't complain that he has no interest in your project at that point. The bridge is burned.by imtringued
5/23/2026 at 9:44:57 AM
I don't know how the author would feel. But, honestly, for a libc replacement, I'd personally be okay with that ...If you can't be bothered to look at a Makefile (or ask an AI to look at the Makefile), you are almost certain to be more trouble than any possible benefit you will bring.
Especially in the realm of open source, I'm becoming increasingly comfortable with "If you can't be bothered to jump through even the most minimal of hoops, please get lost."
by bsder
5/23/2026 at 7:38:15 PM
People are very silly and very entitled. I'd bend over backward to help anyone contribute to or use the library in any way. In response, all I ask is for some common courtesy and friendliness. Spending more than exactly zero seconds on people who won't give you that is a waste of time.In other words, you hit the nail on the head. Anyone who acts this way can get fucked! We'll be having a good time and making friends without them
by dboon