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

181–190 of 222 posts

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

#181

Post by cv5005 »

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…

>There's no namespacing feature provided so you're left with the convention of picking a few letters as a prefix and hoping it doesn't overlap and yet is succinct enough to not be annoying.

I've been using C on a daily basis for 30+ years and name collisions has just never been a problem.

Granted, it might be due to lack of a package manager so micro dependencies ala import is_even is not a thing here, but still, in practice, no name collions occurs.

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

#182

Post by WalterBright »

WalterBright wrote: post #148

Whenever I review C code, I always look for the string functions. About 90% of the time, I find a bug in it. The bug is always about forgetting to account for the terminating 0 byte. The functions strncpy, snprintf, strncat, are fountains of bugs.

P.S. For these reasons I have abandoned the "n" functions, such as strncpy, strncat, etc.

I still use snprintf, though, because it is so darned useful. But I wrap it up in another function after carefully ensuring it is called correctly.

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

#183

Post by ndesaulniers »

I spent a bit of time implementing parts of a C runtime for the brief tenure I had maintaining LLVM's libc. I quickly came the realization that a lot of the interfaces that made it all the way to standardization were trash. How the language is standardized is still comical to me. I agree with TFA that C style strings are trash.

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

#184

Post by fc417fc802 »

Panzerschrek wrote: post #34

This doesn't look good: c8 buf [SP_PATH_MAX] = sp_zero; sp_cstr_copy_to_n(path, len, buf, SP_PATH_MAX); since #define SP_PATH_MAX 4096 There should be a fallback for very long paths.

I'm inclined to agree with you that paths can be arbitrarily long as a matter of principle. However in practice I believe PATH_MAX on most distros defaults to 4096 so if you're going to insist on a hard upper limit it's at least within reason.

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

#185

Post by RedComet »

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…

You didn't write it, though. And it is slop. If you had actually wrote it, you might learn from some of the criticism or be able to engage with it on an objective level.

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

#186

Post by rTX5CMRXIfFG »

yjftsjthsd-h wrote: post #160
dboon wrote: post #141

Earlier quoted context omitted.

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.

I'm seeing that people have a big issue with the language, but "ultra" doesn't even necessarily mean "total"

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

#187

Post by rixed »

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…

I've spent enough time wondering where a given short name was pulled from that i came to see lack of namespace as a quasi feature.

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

#188

Post by schaefer »

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.

> C is horribly and unfixably broken. ... Let's move on.

I love that you are both making this argument and that you have a link to a boutique C compiler written in assembly on your home page.

While I'm commenting on your home page - I recognize that photo as being Red Rock. Possibly pine creek? but can I ask which route specifically?

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

#189

Post by rixed »

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…

HN is for technical discussions. Even if the parent were only judging by his own personal preferences that would be relevant here.

Note: I've written a lot of C by profession and passion, yet I find parent's criticisms mostly valid. At least he did not mention rust ;)

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

#190

Post by trueno »

AlotOfReading wrote: post #55
dboon wrote: post #44

Earlier quoted context omitted.

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

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

people 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

Post reply on HN