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

61–70 of 222 posts

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

#61

Post by tdeck »

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.

Hearing someone mention FreeBASIC really brings me back. It was the first language I ever used pointers in.

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

#62

Post by dboon »

skybrian wrote: post #3

My impression of the sample programs is that they're unreadably noisy, but maybe this would be a good compiler target if you're writing your own language?

How would you write https://github.com/tspader/sp/blob/main/example/ls.c in your statically typed language of choice? To be fair, this is definitely the kindest example to my library, but one reason I felt this project was worth pursuing was that that example reads basically like a slightly worse TypeScript to me. In other words, quite nice for how low level the code really is.

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

#64

Post by scott01 »

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.

I’m not as experienced as some people here, but in ~10 years, I’ve never needed to write code for anything other than x86 or arm. So I agree with the author on their priorities.

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

#65

Post by dboon »

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.

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

#66

Post by flohofwoe »

lelanthran wrote: post #52
ktpsns wrote: post #11

Earlier quoted context omitted.

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

> This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big". The number might just be zero - did anyone check if this compiles? I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined (used in 3x places) but it doesn't appear in the GH search results. I'm not going to clone and build this (too dangerous).

> I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined

A quick glance at the source on github and here you go: https://github.com/tspader/sp/blob/e64697aa649907ce3357a7dd0...

`sp_mem_allocator_alloc_type ` is going through a couple of macro resolutions which ends up at `sp_mem_allocator_alloc`

> I'm not going to clone and build this (too dangerous).

Your computer won't explode just from downloading and compiling some C code, don't worry ;)

The github repo builds and the examples run just fine on macOS by just running `make` in the project directory, although with one warning:

   warning: 'posix_spawn_file_actions_addchdir_np' is deprecated: first deprecated in macOS 26.0

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

#68

Post by dboon »

AlotOfReading wrote: post #8
Retr0id wrote: post #7

Earlier quoted context omitted.

Looks like the default allocator uses mmap(2) for every single allocation , which is horribly inefficient - you map a whole PAGE_SIZE worth of memory for every tiny string. Aside from just wasting memory this will make the TLB very unhappy. It looks like sp_log's string formatting is entirely unbuffered which results in lots of tiny write syscalls.

That seems to be a pretty consistent quality level for the entire library. Look at the implementations in sp_math, yikes.

sp_math.h is, as noted at the top of the file, a repackaging of https://github.com/HandmadeMath/HandmadeMath

It is not part of the core library. It is certainly not meant as a reference-level implementation of math functions. It's there so you can write an easing function for a game without pulling in libc. It seems like its existence has offended you. If that's the case...I'm sorry? At every possible point, I note as loudly as possible exactly what that library is. I found your tone extremely dismissive and disrespectful and I don't care to engage with that any more than I already have.

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

#69

Post by scott01 »

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

Can you show me a realistic case with a longer path?

I have email backups from a provider where filenames are extremely long.

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

#70

Post by mjevans »

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…

For reference, Dialup Internet (E.G. ~2-3KByte/sec transfer) was NOT uncommon even into the early 2000s.

In 1994 even dialup internet connections were rare and most software distribution occurred by floppy disk (encased in hardshell plastic). _storage_ space was also at a major premium with internal hard disk size indexed in CHS rather than LBA and new (rarely seen by most end consumers) models barely passing 1GB in capacity. https://en.wikipedia.org/wiki/Seagate_Barracuda

Even in the early 'dot com' era as DSL and early cable modem became common downloading software updates could still be painful, though far less so than hours or days on dialup.

Post reply on HN