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

211–220 of 222 posts

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

#211

Post by yjftsjthsd-h »

bryanlarsen wrote: post #207
yjftsjthsd-h wrote: post #160

Earlier quoted context omitted.

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

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

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.

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

#212

Post by YourDadVPN »

xorvoid wrote: post #173

They're just inventing another language here. That's fine if you want to do that. Just do THAT. C is horribly and unfixably broken. We've known that for many decades. Just let it die already! Let's move on.

There isn't a language that achieves C's performance, access to hardware and portability while also having superior syntax. The reason C is hard is because it makes sacrifices to enable the above. A Rust (for example) compiler targeting many microcontrollers (8/16-bit word size (not all), Harvard architectures like AVR, non-8-bit byte) simply can't be written due to assumptions made by the spec. Many such architectures are still in use.

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

#213

Post by thayne »

HexDecOctBin wrote: post #45
alfiedotwtf wrote: post #35

Earlier quoted context omitted.

Making every C call a system call is not a good idea at all - think about malloc() etc - the OS shouldn’t care about individual allocations and only worry about providing brk() etc. otherwise, performance will die if you’re doing a thousand system calls per second!

No modern libc uses (or should use) brk() as the heap. Allocate virtual memory using mmap, VirtualAlloc, etc., and manage your set of heaps.

I believe glibc uses both mmap and brk depending on the situation.

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

#214

Post by kazinator »

hnlmorg wrote: post #202
kazinator wrote: post #168

Earlier quoted context omitted.

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

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

In context, they probably mean portable by installed base of targets. In a world in which nothing but ARM cores exist, a machine language ARM program is portable, and even "extremely" so.

There is a usage of "portable" which has to do with percentage of installations it runs in or can be easily made to run in, regardless of how much has to be changed to get it working anywhere else.

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

#215

Post by thayne »

flohofwoe wrote: post #97
tialaramex wrote: post #85

> I’ve been working on fixing C by giving it a high quality, ultra portable standard library If the only problem with C was that the stdlib is terrible that would be a very different situation. There are much more fundamental problems with the language. Problems that are entirely understandable in K&R C but aren't acceptable half a century later. A "high quality" standard library can't fix these problems. In some cas…

These are all just your personal preferences. Just use another language instead which better matches your taste, nobody forces you to use C and there are plenty of more opinionated alternatives. FWIW, the standard library being stuck in the K&R era is an actual problem since it doesn't make use of more modern language features and some functions are downright footgun magnets, but nobody quite agrees what a modern std…

> Just use another language instead

That isn't really an option if you are working on an existing project written in c.

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

#216

Post by vetrom »

dboon wrote: post #76
riedel wrote: post #30

Earlier quoted context omitted.

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.

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

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.

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

#218

Post by kjs3 »

Brian_K_White wrote: post #176
kjs3 wrote: post #164

Earlier quoted context omitted.

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.

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.

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

#219

Post by 12_throw_away »

12_throw_away wrote: post #133
dboon wrote: post #72

Earlier quoted context omitted.

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…

> It's unbelievably rude to call it vibecoded slop Could you clarify how much of this code and blog post was written by an LLM?

well, no response is still a kind of response

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

#220

Post by hnlmorg »

kazinator wrote: post #214
hnlmorg wrote: post #202

Earlier quoted context omitted.

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

In context, they probably mean portable by installed base of targets. In a world in which nothing but ARM cores exist, a machine language ARM program is portable, and even "extremely" so. There is a usage of "portable" which has to do with percentage of installations it runs in or can be easily made to run in, regardless of how much has to be changed to get it working anywhere else.

You are using the term incorrectly.

As I said before:

> “Portable”, in the context of how it was used, generally refers to software using platform agnostic idioms.

Words have meanings. If the code is tied to an architecture then it isnt portable. And as you said, there’s nothing wrong with that. But arguing some other definition of a word people are already using is just stupid.

Post reply on HN