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
