Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

sp.h: Fixing C by giving it a high quality, ultra portable standard library

spader.zone

Post reply on HN
Print view View original

171–180 of 222 posts

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#171

Post by [deleted] »

fithisux wrote: post #22
zzo38computer wrote: post #19

I agree with most of the criticisms they make. I agree that pointer and length is better than null-terminated strings (although it is difficult in C, and as they mention you will have to use a macro (or some additional functions) to work this in C). Making the C standard library directly against syscalls is also a good idea, although in some cases you might have an implementation that needs to not do this for some re…

Null terminated strings have some merits but they should be a completely different data type like in Freebasic.

[deleted]

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#172

Post by [deleted] »

Sankozi wrote: post #27
fithisux wrote: post #22

Earlier quoted context omitted.

Null terminated strings have some merits but they should be a completely different data type like in Freebasic.

Are there other merits than availability of literals in C? It seems like one of the worst data structures ever - lookup complexity of a linked list with a expansion complexity of an array list with security problems added as a bonus.

[deleted]

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#174

Post by [deleted] »

dboon wrote: post #72
504118318 wrote: post #33

Just taking a quick look at the atomics section: First, (on unix) it's wrapping pthread mutex. That's part of libc! (Technically it might not be libc.so, but it's still the standard library.) Also, none of the atomics talk about the memory model. You don't _have_ to use the C11 memory model (Linux, for example, doesn't). But if you're not using the C11 memory model and letting the compiler insert fences for you, you…

Yes, unfortunately the threading primitives require libc. Ditto subprocesses. It's on my list. But regarding: "Oops... apparently this is vibecoded. Welp, I just wasted ten minutes of my life reviewing slop that I'm not going to get back." Do not talk to people like this. I don't care if you don't like the library, or if you found a flaw in it. I am a regular person who wrote this code for no other reason than I thou…

[deleted]

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#175

Post by [deleted] »

dboon wrote: post #123
504118318 wrote: post #120

Earlier quoted context omitted.

You're absolutely right. I should have expressed my late-night frustration more kindly.

No problem and thanks for the apology. Happens to the best of us. Regardless, thanks for the comment — I definitely didn’t mean to slip by the pthread stuff on a “well technically this isn’t libc.so”. It’s just code that’s pretty hard to get right and I haven’t had a chance to rewrite it!

[deleted]

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#176

Post by Brian_K_White »

kjs3 wrote: post #164
nine_k wrote: post #137

Earlier quoted context omitted.

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.

portable is a different word from ported.

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#177

Post by nine_k »

fc417fc802 wrote: post #170
nine_k wrote: post #140

Earlier quoted context omitted.

But (i32 length, byte[] data) is as complex as (byte[] data, '\0'), its two-parts anyway. Of course it allows potentially for very long strings at the cost of just a single byte spent as a terminator. Beside the rarity of such a case, the "space savings" might play a role on a PDP11, or on a Z80, but not on any of the modern architectures that need structures aligned to 32 or even 64 bit boundary. The efficiency and…

Arrays as glorified pointers were the mistake. Null terminated strings are a natural result of that design choice. Null pointers however were not a mistake, despite how popular slandering them has become. A reasonable case can be made that any modern language should enforce null checks (and bound checks, and ...) or at the least provide them by default but that is neither here nor there as far as C is concerned.

Tony Hoare himself called NULL a mistake. But the problem is not in the ability to set a pointer to a null value, of course. The problem is that all pointers are nullable, and there's no way to statically enforce their being non-null. I wonder how feasible data flow analysis would be in 1969 though.

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#178

Post by floxy »

nine_k wrote: post #137
bryanlarsen wrote: post #111

Earlier quoted context omitted.

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 runni…

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.

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

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#179

Post by murderfs »

kevin_thibedeau wrote: post #165
murderfs wrote: post #163

Earlier quoted context omitted.

> 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 'ext…

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

Re: sp.h: Fixing C by giving it a high quality, ultra portable standard library

#180

Post by norir »

Sankozi wrote: post #27
fithisux wrote: post #22

Earlier quoted context omitted.

Null terminated strings have some merits but they should be a completely different data type like in Freebasic.

Are there other merits than availability of literals in C? It seems like one of the worst data structures ever - lookup complexity of a linked list with a expansion complexity of an array list with security problems added as a bonus.

When using null terminated strings, parsing can be branchless because you don't need bounds checks and can use a jump table indexed by the byte.
Post reply on HN