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 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.
All that is required is to declare a global setjmp buffer, and then each API function would do a setjmp before calling into the existing code... and you ignore that code if the longjmp is called. Then you simply need to close any files that were opened and change working-directory if it might have been changed, then return from the API. Then in any of the places that exit is called, add a test to see if you were called by an API function and if so do the longjmp instead. It's a few dozen lines of code (in addition to the actual API interface code). Sure seems like worth the experiment to me! ../Dave On 24 June 2018 at 16:34, Richard Hipp <d...@sqlite.org> wrote: > On 6/16/18, Stephan Beal <sgb...@googlemail.com> wrote: > > > > 3) Fossil effectively uses exit() to handle just about any type of > > non-allocation error. i.e. there's little library-friendly error handling > > in fossil. > > Not just errors. If Fossil finds an opportunity to send a "304 Not > Modified" reply, it does so and then immediately calls exit(0), > without having to unwind the stack. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > 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
