[nextaccountic]

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

[bryanlarsen]

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.

[dboon]

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.

[yjftsjthsd-h]

That's fine. Just don't call it "ultra portable" while treating it as a non-goal.

[bryanlarsen]

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

[yjftsjthsd-h]

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.

[rTX5CMRXIfFG]

I'm seeing that people have a big issue with the language, but "ultra" doesn't even necessarily mean "total"

[yjftsjthsd-h]

Ultra might be a step below total, but the 3 most common OSs on the 2 most common ISAs is ... several steps below ultra.

[nine_k]

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.

[kjs3]

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.

[Brian_K_White]

portable is a different word from ported.

[kjs3]

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.

[floxy]

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

[magicalhippo]

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

[king_geedorah]

Portability across compilers is orthogonal to portability across target architectures.

[thayne]

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.

[king_geedorah]

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.

[kazinator]

You can be portable, without supporting obscure platforms.

Supporting obscure platforms is what makes portability "extreme", though.

[hnlmorg]

“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”

[kazinator]

Is the Foo kernel 75% of the code base, 5% or 0.01%?

[hnlmorg]

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.

[kazinator]

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.

[hnlmorg]

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

[imtringued]

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.

[murderfs]

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

[kevin_thibedeau]

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.

[murderfs]

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

[ktpsns]

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

[noosphr]

We support extreme portability for sufficiently large values of two.

[egl2020]

When I was a wee lad, a conference speaker announced that "portability" meant "runs on anything that supports OS/360".

[lelanthran]

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

[flohofwoe]

> 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:

   warning: 'posix_spawn_file_actions_addchdir_np' is deprecated: first deprecated in macOS 26.0

[dboon]

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

[rswail]

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.

[locknitpicker]

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

[jamespo]

Compiling

[pjmlp]

Depends how compiling actually happens in practice, what executables and scripts are called.

[lmz]

"I have no idea how that rm -rf $HOME ended up in the Makefile"

[flohofwoe]

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 store

[pseudohadamard]

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?

[lelanthran]

> 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 :-/

[flohofwoe]

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

[rigonkulous]

Use better tooling, then. Cscope is your friend.

[forgotpwd16]

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

[rigonkulous]

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

[dboon]

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?

[taneq]

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.

[AlotOfReading]

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.

[trueno]

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

[scott01]

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.

[hnlmorg]

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.

[sitzkrieg]

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 rules

[forrestthewoods]

That’s a lot of text to say “well ackshually”.

[riedel]

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.

[forrestthewoods]

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

[dboon]

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

[vetrom]

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.

[bsder]

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?

[imtringued]

You've rejected a user. You can't complain that he has no interest in your project at that point. The bridge is burned.

[bsder]

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

[dboon]

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