There is nothing wrong with a C library handling its internal processing using setjmp/longjmp, as long as there's no C++ callbacks or any other way that C++ code that might use throw/catch can be executed from within calls to that library.
It's a little bit more work than just replacing the calls to exit with longjmps. There are 5 OS resources that exit resolves: CWD, open files, memory, child processes, and the stack. stejmp/longjmp only directly resolves the stack, but it provides a hook to resolve the others. Fossil appears to be careful with memory allocation too, with very few raw calls to malloc, so memory allocaions can be unwound. Again, chdir, and fopen are rarely used raw, so they can also be unwound. (opendir is called raw in a few places, so they may need a fossil_opendir) So as I originally said... its a pretty small amount of overhead code to write to do the cleanup. BUT, the big advantage is that then libfossil *automatically* gets all the fossil bug-fixes and some of the improvements for free! Sure seems worth it to me. (Note that 3 files that might be the biggest problem: sheel.c, fshell.c, and main.c) wouldn't be part of libfossil. ../Dave On 25 June 2018 at 09:52, Dominique Devienne <ddevie...@gmail.com> wrote: > On Mon, Jun 25, 2018 at 2:30 PM Warren Young <war...@etr-usa.com> wrote: > >> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal <sgb...@googlemail.com> >> wrote: >> >>> Isn't adding hundreds (literally) of gotos just as fraught with >>> opportunities for failure ;)? >>> >> >> #ifdef LIBFOSSIL >> # define FOSSIL_EXIT(n) longjmp(blabla) >> #else >> # define FOSSIL_EXIT(n) exit(n) >> > #endif >> > > If there's a libfossil ever, it should be C++ friendly IMHO, i.e. not use > longjmp :) > > But whether it's C's longjmp or C++ throw, that doesn't solve the fact > fossil doesn't > cleanup after itself properly, simply because it's exit() based, thus lets > the OS reclaim > memory, and I guess all other resources like sockets, etc... That's > obviously a nonstarter > for a library, evidenced by all the end/free/finish APIs in SQLite, and > value destructors > passed to other APIs. My $0.02. --DD > > PS: My own interest in fossil is not in its "less core" Sam advocates for, > although > I do find that prospect very interesting and worthwhile, but it's > "fast-enough HTTP > server and web-app framework" in C using a lightweight template engine > (TH1), FWIW. > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
