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

151–160 of 222 posts

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

#151

Post by WalterBright »

x0re4x wrote: post #150
WalterBright wrote: post #138

https://spader.zone/sp/#null-terminated-strings-are-the-devi... Pointer/length is not just for strings - but for all arrays. See my proposal: https://www.digitalmars.com/articles/C-biggest-mistake.html

I suggest using a slightly different array operator syntax for fat pointer arrays: "char a[|..|]" instead of just "char a[..]" to make them visually distinct and indicate that element access has additional bounds check. (syntax inspired by ocaml)

Thank you for the idea! I have no experience with Ocaml, so have no opinion on it. My experience is the simpler the syntax, the more people will use it.

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

#152

Post by secondcoming »

WalterBright wrote: post #138

https://spader.zone/sp/#null-terminated-strings-are-the-devi... Pointer/length is not just for strings - but for all arrays. See my proposal: https://www.digitalmars.com/articles/C-biggest-mistake.html

But won't all those posix functions that take only `const char*` parameters need to be changed to be pointer/length?

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

#153

Post by egl2020 »

ktpsns wrote: post #11
nextaccountic wrote: post #9

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

Exactly. This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big".

When I was a wee lad, a conference speaker announced that "portability" meant "runs on anything that supports OS/360".

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

#154

Post by uecker »

Luker88 wrote: post #146

> C is valuable because it’s simple This is funny to me because just today some friends gave me a link to a C quiz: https://stefansf.de/c-quiz/ From which I gathered that it is a much more cursed language than I remembered. Maybe we all just got used to C and just happen to use a minimal subset. The problems with C are not mainly with the standard library, but any effort to improve things should be lauded.

The quiz is not entirely accurate though. For example, pointers to the same address must compare equal. Other stuff is ancient and some of it was already removed in C23. Again other things are entirely irrelevant in practice and kept only for backwards compatibility or for specific technical reasons. In practice, C is very simple, at least compared to the alternatives.

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

#155

Post by skydhash »

Luker88 wrote: post #146

> C is valuable because it’s simple This is funny to me because just today some friends gave me a link to a C quiz: https://stefansf.de/c-quiz/ From which I gathered that it is a much more cursed language than I remembered. Maybe we all just got used to C and just happen to use a minimal subset. The problems with C are not mainly with the standard library, but any effort to improve things should be lauded.

There's C the standard, and there's C the implementation (compiler & platform). The standard is nice to have on a bookshelf, but your main reference should be the implementation.

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

#156

Post by spxtr »

504118318 wrote: post #120
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…

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

I thought this was a hilarious comment, for what it's worth.

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

#158

Post by hnlmorg »

kazinator wrote: post #122
hnlmorg wrote: post #83

Earlier quoted context omitted.

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

Is the Foo kernel 75% of the code base, 5% or 0.01%?

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

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

#159

Post by charcircuit »

dboon wrote: post #65
charcircuit wrote: post #47

I do not want to include and compile a standard library for every file that includes it. Why do standard library headers always have to be insane?

Have you considered compiling it into a binary of your choice? It works perfectly well as a traditional library. The only cost you pay is re-parsing the header part once per TU. Because C is so simple, this is virtually free. In any case, calling it insane makes me feel disrespected and I would prefer if you didn't do that.

>The only cost you pay is re-parsing the header part once per TU.

You are not just parsing it. The header includes the implementation too which will get compiled. Then the linker has to do extra work in order to deduplicate all of this extra code that was made.

>Because C is so simple, this is virtually free.

This is not virtually free needing to compile a standard library for every file in one's project.

>In any case, calling it insane makes me feel disrespected

I would recommend you not take it personally. Fortunately, for better or worse software ends up being pretty robust so it can tolerate a lot. Even if you have to recompile the same standard library hundreds of times, it will eventually compile.

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

#160

Post by yjftsjthsd-h »

dboon wrote: post #141
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…

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

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