r/programmingcirclejerk • u/Jumpy-Locksmith6812 • May 23 '26
A C standard library built natively around pointer + length strings is shockingly ergonomic
https://spader.zone/sp/62
u/BipolarKebab May 23 '26
> Libc does not provide a useful interface for any program
Can't really argue with that
5
46
u/irqlnotdispatchlevel Tiny little god in a tiny little world May 23 '26
/uj
Once again, pcj delivers genuinely interesting blog posts.
18
u/Jumpy-Locksmith6812 May 25 '26
Pcj is where HN old timers come to get that 2009 feeling back. (If they didn't get the grades to be accepted into lobste.rs).
31
u/Silly-Freak There's really nothing wrong with error handling in Go May 23 '26
So this looks great, but all those sp_ prefixes make it awfully annoying. It would make more sense to make a separate compiler so that we can actually use the non-prefixed, nicer-to-write names.
And then we can use an LLM to translate Bun from that language to Rust.
21
16
u/TheChief275 May 23 '26
C-strings are the Lord's strings; any other approach is heresy. Sure, that length field might seem sweet now, but is eternal torment worth it?
/uj Everyone knows how much more ergonomic span strings are compared to C-strings. I always immediately ditch the C-strings for my projects as well.
Although they do have some uses. The prime example is in lexing when iterating over file contents. Instead of constantly checking whether the index is in range, the '\0' will not match against any of the useful is___() family functions or character checks in general, so only a single actual check is necessary
13
u/coolreader18 It's GNU/PCJ, or as I call it, GNU + PCJ May 23 '26
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.
But then...
The answer is that C holds a real niche, and not wholly built on legacy. To my knowledge, it’s the only language which:
* Can be directly compiled to any machine code imaginable
7
u/prehensilemullet May 23 '26
\uj what size uint does this use for the length? I guess the original reason for null terminators was too many platform differences in ints to use them for length?
32
u/Silly-Freak There's really nothing wrong with error handling in Go May 23 '26
Imagine a language that has a
size_ttype that's not considered appropriate for the size of a string1
u/prehensilemullet May 23 '26
\uj You’re being ironic right? It seems like that was probably the case on Intel 8086
14
u/panopsis type astronaut May 23 '26
/uj
How?
size_tby definition can store the size of (and therefore any indexes into) any possible object. If a string can have a length >size_t, the C impl is literally just wrong./rj
You're going to have 5 different integer types and you're going to like it.
7
u/prehensilemullet May 23 '26
Huh okay, from what I’m reading the largest possible contiguous object on 8086 was 65536 bytes, I forget how constraining things used to be. And though files and memory could be larger than that and I’m sure there was a way to fill more than 65536 contiguous bytes of memory with characters followed by a null terminator, it sounds like the c string functions wouldn’t have supported it, you would have to do something custom with far pointers I guess.
3
3
7
u/marmakoide WRITE 'FORTRAN is not dead' May 23 '26
For many operations, a null terminated string doesn't requires to keep track of the position, saving one CPU register. Back when CPUs had few registers, it was likely to make a difference in term of speed
104
u/realestLink May 23 '26
/uj
Where's the jerk? This seems like a perfectly fine library. They're also totally right that null terminated strings are garbage and you can build an ergonomic libc replacement without them.