Actually, setjmp/longjmp isn't goto, it's try-catch/throw. It unwinds the stack, so you can only (correctly) longjmp to a point that is in the current call-chain. Of course, this is C, so you can screw it up, but said screw-ups are not subtle! And subtle bugs are the ones to worry about.
I count 35 direct uses of exit() (2 in fossil_panic, and one in fossil_exit). I don't know why those 32 calls to exit() don't call fossil_exit - perhaps they don't want the db closed... but if you replace those 35 calls with a call to fossil_exit_now then there would be only 1 place that had to do the longjmp logic. There is often value in re-implementing programs! All I really said was that it was a mug's game unless fossil-the-program is going to adopt it, because you'd be constantly tracking the changes of fossil-the-program in the re-implemented libfossil code. I unfortunately don't have the time at the moment, or I would certainly try the experiment. I suspect your work on libfossil would be an excellent API definition! Perhaps I can find a student I could interest in the project in the fall. ../Dave On 24 June 2018 at 18:48, Stephan Beal <sgb...@googlemail.com> wrote: > On Sun, Jun 24, 2018 at 11:19 PM David Mason <dma...@ryerson.ca> wrote: > >> I really don't understand the reticence to use setjmp/longjmp to turn all >> of these short-cut exits into library return-to-API trampolines. It >> > > To be clear: that's my reticence, not Richard's. libfossil was always > effectively a third-party effort which had Richard's blessing. > > My aversion to setjmp/longjmp is that they're effectively global gotos, > and gotos, except in very tightly-controlled circumstances, quickly > produces spaghetti messes. > > would allow you to retain all the existing fossil codebase. Rewriting the >> code into library form is an interesting project, but it seems like a huge >> amount of work and unless Richard is going to change fossil to use the API, >> it is also going to be a huge ongoing maintenance nightmare and fraught >> with opportunities for failure. >> > > Isn't adding hundreds (literally) of gotos just as fraught with > opportunities for failure ;)? > > It's a few dozen lines of code (in addition to the actual API interface >> code). Sure seems like worth the experiment to me! >> > > i'll go make some popcorn :). > > (To be fair: my [strong] aversion to that solution isn't intended to imply > that you can't pull it off. My journey with libfossil was always _at least_ > as much about reimplementing it "cleanly" as it was about getting it > running at all. Without the former, the latter would have been, at best, a > hollow success.) > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > _______________________________________________ > 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
