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

141–150 of 222 posts

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

#141

Post by dboon »

bryanlarsen wrote: post #111
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…

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 programs in C is a good idea, and those are the programs that I write, so that's where my focus is. But if someone would like to come along and write the ~30 syscalls needed to port the library to a new platform, or even register any interest in such, I'd be happy to look into it at that point.

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

#142

Post by CyberDildonics »

rmunn wrote: post #20
smitty1e wrote: post #17

Earlier quoted context omitted.

Family saying: "It ain't bragging if you can do it." When one is competent to work at this level, strong opinions are in order. Their correctness is something I cannot gage. I'm barely competent to follow the conversation.

Considering the first thing I saw in the thread was https://news.ycombinator.com/item?id=48244891 where the values returned from sp's sine function was compared to the correct values, I'm going to take any such opinions with a few grains of salt. Because the correct sine for the number they tested (31337 radians) is 0.3772 (0.3771522646 according to my calculator), sp's implementation returned 0.4385. That's not even…

I was promised by the title that it is "high quality"

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

#143

Post by dboon »

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

A comment from a legend. Thanks for reading and thanks for the response! I agree; the dynamic array is typed as a T* for ergonomics sake but is similarly a pointer and a length (and an allocator).

Could I pick your brain a little more on the design? I'm spader at spader.zone; if you have time, drop me an email. I promise not to take too much of your time and I'd love to hear from you.

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

#144

Post by dboon »

NetMageSCW wrote: post #130
dboon wrote: post #56

Earlier quoted context omitted.

The point of the library is that you do not call the low level allocation primitive to allocate a single string. Of course, in simple programs which exit immediately, there is no difference between using a page allocator and a heap allocator. In real programs, I use an appropriate allocator for the allocation rather than making arbitrary calls to malloc(). In the sp.h examples, I use the page allocator to keep freest…

So every program using sp has to re-invent malloc or multiple copies of their own bespoke allocator and this is supposed to be a good idea?

The library provides a few basic allocators.

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

#145

Post by WalterBright »

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

A comment from a legend. Thanks for reading and thanks for the response! I agree; the dynamic array is typed as a T* for ergonomics sake but is similarly a pointer and a length (and an allocator). Could I pick your brain a little more on the design? I'm spader at spader.zone; if you have time, drop me an email. I promise not to take too much of your time and I'd love to hear from you.

Thanks for the kind words!

This can get you started:

https://dlang.org/spec/arrays.html

Strings (and arrays) being length/ptr is a freaking enormous win, in simplicity, performance, and overflow bug elimination.

One of D's secret features is that string literals still have a 0 appended to them, even though the length of the string does not include the 0. This makes it super slick to call C functions, like printf, using a string literal for the format string.

I'm baffled why C spends its energy doing things like normalized Unicode identifiers (an abomination) instead of something incredibly useful like length/ptr arrays.

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

#146

Post by Luker88 »

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

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

#147

Post by Luker88 »

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 today some friends sent me this: https://stefansf.de/c-quiz

Yesterday I would have agreed that C is a nice and simple language, today I believe it is a cursed one that we just happen to make work somehow.

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

#148

Post by WalterBright »

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.

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

#149

Post by Luker88 »

ozgrakkurt wrote: post #119
pjmlp wrote: post #29

We should have left C in the 90's already, but then FOSS happened, "Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C." The GNU Coding Standard in 1994, http://web.mit.edu/gnu/doc/html/sta…

C is the only language I found where it is possible to isolate yourself from the "AMAZING" ideas of programming language creators. There is no language other than C and C++ that is mature enough that you can actually discard the implicit runtime stuff and still be able to code in the language. C++ is too complex in my opinion so I only get to use C as a minimal language. Even if you look at a language like Zig. You h…

C is cursed, too. Just in a different way

https://stefansf.de/c-quiz/

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

#150

Post by x0re4x »

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)
Post reply on HN