4 ms·
> 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 mac
by nextaccountic 5mo 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.
- ktpsns 5mo agoExactly. This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big".
- noosphr 5mo agoWe support extreme portability for sufficiently large values of two.
- lelanthran 5mo ago> 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 5mo ago> 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/e64697aa649907ce3357a7dd00ff259bb3928498/sp.h#L7997-L7999 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 5mo agoIt looks like I need to update my macOS machine! Thanks for the sanity, and thanks for reading.
- rswail 5mo agoOnly 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 5mo ago> 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".
- forgotpwd16 5mo ago> 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 5mo agoFor C-based projects, use cscope. It found it pretty fast.
- egl2020 5mo agoWhen I was a wee lad, a conference speaker announced that "portability" meant "runs on anything that supports OS/360".
- riedel 5mo agoI 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 5mo ago> 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.
- bsder 5mo agoYou 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 5mo agoYou've rejected a user. You can't complain that he has no interest in your project at that point. The bridge is burned.
- bsder 5mo agoI 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."
- deleted 5mo ago[deleted]
- kazinator 5mo agoYou can be portable, without supporting obscure platforms. Supporting obscure platforms is what makes portability "extreme", though.
- hnlmorg 5mo ago“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 5mo agoIs the Foo kernel 75% of the code base, 5% or 0.01%?
- hnlmorg 5mo agoI’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 5mo agoPortable 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.
- forrestthewoods 5mo agoThat’s a lot of text to say “well ackshually”.
- dboon 5mo agoThere 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?
- AlotOfReading 5mo agoThe 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.
- scott01 5mo agoI’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 5mo agoNot 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 5mo agoin 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
- trueno 5mo agopeople 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
- imtringued 5mo agoYeah 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.
- bryanlarsen 5mo agoIt'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.
- nine_k 5mo agoAren'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 5mo agoThe 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 5mo agoportable is a different word from ported.
- kjs3 5mo agoYes, 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.
- 5mo ago
- king_geedorah 5mo agoPortability across compilers is orthogonal to portability across target architectures.
- thayne 5mo agoThis 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 5mo agoThe section with heading "Be Extremely Portable" seems relatively clear to me, but perhaps that is just because I already understand host vs target compatibility.
- murderfs 5mo ago> 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 5mo agoIt 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 5mo agoI was making a general point about portability, not this library in particular. I wouldn't consider "only x86_64 and aarch64" as being "portable".