121–130 of 222 posts
Zig, one of the giants upon whose shoulders this library stands, coined a name for this almost-but-not-quite-UTF encoding: WTF-8 and WTF-16. These encodings mean, simply, the same as their UTF counterpart but allowing unpaired surrogates to pass through. To give credit where credit is due, both WTF-8 and WTF-16 were devised by Simon Sapin [1] and Zig simply picked them up. [1] https://wtf-8.codeberg.page/ sizeof((T){…
Earlier quoted context omitted.
You can be portable, without supporting obscure platforms. Supporting obscure platforms is what makes portability "extreme", though.
“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”
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.
How do they all know that it is vibe-coded? I missed the meeting where they were handing out vibe-code-detectors? Please, describe.. P.S. sad to see that HN becomes a witch hunting place
Earlier quoted context omitted.
q> sp_log() writes directly to an IO writer. An IO writer can be buffered or unbuffered, but is unbuffered by default. This is a feature, not a bug. Have a look through the IO code! Why is the unbuffered default? Is there any thoughts on this?
A buffered file may not be fully written to disk if the program exits suddenly. That’s generally a highly undesirable trait for a log file.
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…
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…
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!
Earlier quoted context omitted.
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 a…
I saw the note and ignored it because it's not actually a repackaging of HHM. It simply happens to define a few vaguely similar functions. It doesn't reuse the naming conventions (MulVec3f vs vec3_scale), it doesn't reuse the interface (see SP_MATH_IMPLEMENTATION), and it's missing genuinely useful bits like the matrix functions.
Moreover, the quality of what's been added is significantly worse. Look at sp_sys_expf:
f32 sp_sys_expf(f32 x) {
f32 result = 1.0f;
f32 term = 1.0f;
for (int i = 0; i Also, because sp_math doesn't use FMAs, your library isn't reproducible. Different compilers will produce different values. Reproducibility is a pretty nice property in games.
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.
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…