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.

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

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.

We support extreme portability for sufficiently large values of two.

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

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

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

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

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

  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?