Comment by nextaccountic
2 days ago
> 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.
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.
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.
That's fine. Just don't call it "ultra portable" while treating it as a non-goal.
4 replies →
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.
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.
2 replies →
>now-fringe architectures like MIPS
For those not in the know, Microchip still produces MIPS microcontrollers:
https://www.microchip.com/en-us/products/microcontrollers/32...
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].
[1]: https://www.silabs.com/mcu/8-bit-microcontrollers
[2]: https://www.stcmicro.com/stc/stc32g.html
Portability across compilers is orthogonal to portability across target architectures.
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.
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.
> 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.
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).
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.
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".
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”
Is the Foo kernel 75% of the code base, 5% or 0.01%?
4 replies →
Exactly. This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big".
We support extreme portability for sufficiently large values of two.
When I was a wee lad, a conference speaker announced that "portability" meant "runs on anything that supports OS/360".
> 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 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:
12 replies →
> 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.
For C-based projects, use cscope. It found it pretty fast.
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?
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.
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
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.
2 replies →
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.
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.
That’s a lot of text to say “well ackshually”.
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!
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.
> 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.
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?
Or you could actually try the compliance suite on an architecture and report back to us if it works?
You've rejected a user. You can't complain that he has no interest in your project at that point. The bridge is burned.
2 replies →