2 ms·

> Debian's developers ... considered rebuilding all of Perl and then, perhaps, all (500 or so) packages depending on the PNG library libpng using setjmp.h for

> Debian's developers ... considered rebuilding all of Perl and then, perhaps, all (500 or so) packages depending on the PNG library libpng using setjmp.h for error handling was always my least favorite part of libpng, especially since the libpng documentation indicates it was just done for convenience (tell that to the authors of the OP!): > The motivation behind using setjmp() and longjmp() is the C++ throw and catch exception handling methods. This makes the code much easier to write, as there is no need to check every return code of every function call.

kragen 5y ago
It's not just convenience for the authors of libpng; it's also convenience for libpng's users, because it means they can handle errors at a single location instead of checking the return code of every function call. It is true that changing the size of jmp_buf breaks binary compatibility, but that's hardly a unique fatal flaw in setjmp/longjmp; it's also true of fd_set, struct timeval, struct tm, struct sockaddr, struct stat, and all the other exposed memory-layout interfaces mentioned in the article: __pthread_unwind_buf_t, PerlInterpreter, png_struct_def, etc. Indeed, you'd think it would be much less of a problem for jmp_buf, because normally the things stored in a jmp_buf are precisely the callee-saved registers in your ABI; changing that involves comprehensively breaking your ABI anyway. There is a big advantage in C to exposing the memory layout of a struct in this way: it doesn't need to be heap-allocated, so it doesn't introduce a dependency on heap allocation (which wasn't part of the standard library at all when setjmp was defined, and is still forbidden in many contexts), and you can statically bound your program's memory use, so you can be sure it won't fail. Heap allocation can always fail, so you can only ever use it in programs where failure is an option. You don't want your antilock braking system to raise an exception and reboot because its heap has become fragmented.

kragen 5y ago

It's not just convenience for the authors of libpng; it's also convenience for libpng's users, because it means they can handle errors at a single location instead of checking the return code of every function call. It is true that changing the size of jmp_buf breaks binary compatibility, but that's hardly a unique fatal flaw in setjmp/longjmp; it's also true of fd_set, struct timeval, struct tm, struct sockaddr, struct stat, and all the other exposed memory-layout interfaces mentioned in the article: __pthread_unwind_buf_t, PerlInterpreter, png_struct_def, etc. Indeed, you'd think it would be much less of a problem for jmp_buf, because normally the things stored in a jmp_buf are precisely the callee-saved registers in your ABI; changing that involves comprehensively breaking your ABI anyway. There is a big advantage in C to exposing the memory layout of a struct in this way: it doesn't need to be heap-allocated, so it doesn't introduce a dependency on heap allocation (which wasn't part of the standard library at all when setjmp was defined, and is still forbidden in many contexts), and you can statically bound your program's memory use, so you can be sure it won't fail. Heap allocation can always fail, so you can only ever use it in programs where failure is an option. You don't want your antilock braking system to raise an exception and reboot because its heap has become fragmented.