> a "PNG four byte integer", which is limited to the range 0 to 231-1, to defend against the existence of C programmers.
Kind of an odd thing to say, considering the existence and prevalence of libpng, which is written in C, and which uses setjmp() and longjmp() as part of its API. It's difficult to think of a more ill-advised and bonkers but extremely C-centric thing to do.
I guess that's one important reason why stb_image.h became so popular. Last time I tried to integrate libpng into a project I just gave up (that was on Windows, I guess on Linux it would just be an 'apt install libpng-dev').
Are there reasons to interpret `setjmp` and `longjmp` as anything other than a `C` (/hardware) representation of Effects? (In the sense of exceptions, coroutines/await, etc.)
If so, then why aren't they fundamentally quite reasonable?
Some platforms don't support full setjmp/longjmp feature set (WASM for instance). As far as I'm aware libpng also works without setjmp/longjmp support though via a build config option (it's still not fun to integrate into a project if you need to build it from source).
As of libpng 1.6.0, a so-called "simplified API" was added, which does not use setjmp/longjmp. A while back I had a C project using the old API, and I converted it to C++, and the interaction of setjmp/longjmp with exceptions was giving me headaches. I switched to the simplified API, and it was a breeze. So much less code, and no hacky C "exceptions". If you can require libpng 1.6 or newer, it's worth looking at the simplified API, if it supports your needs.
Kind of an odd thing to say, considering the existence and prevalence of libpng, which is written in C, and which uses setjmp() and longjmp() as part of its API. It's difficult to think of a more ill-advised and bonkers but extremely C-centric thing to do.