On Mon, Jun 18, 2018 at 4:54 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Sun, Jun 17, 2018 at 11:11 PM Sam Putman <atmanis...@gmail.com> wrote: > >> On Sun, Jun 17, 2018 at 6:39 AM, David Mason <dma...@ryerson.ca> wrote: >> >>> Just had a quick thought that might make the conversion to library much >>> easier. >>> >>> If you have a relatively small API interface, each of the API functions >>> could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h >>> >> >> > This is the kind of approach I glossed over as a "goto cleanup", so we're >> on >> the same track here. >> >> I haven't had a chance to go over some of the core C files in libfossil >> yet, >> curious to what degree it follows this pattern already. >> > > i have to admit that you lost me at setjmp. There are certain C APIs which > i won't touch unless absolutely forced to, and setjmp/longjmp belong to > that category. gotos are widely used in libfossil to simplify error > handling/deallocation within a given function. > > setjmp/longmp are of course weapons of awesome power. In this context, just a way of goto jumping farther than goto alone allows for. Never use them when a simple goto will do, and it sounds like it will. I think the proposal was to replace every crash with the same longjmp, to simplify porting the code, but you've already taken the time to do it right. In libfossil, all error state is propagated as an integer, with some cases > providing additional information in an Error object owned by the Context > object (each Context manages, at most, one opened repo instance). The API > docs describe, where relevant, which result codes must be considered > fatal/unrecoverable (allocation error being the primary case). An example > of propagating more information is SQL query preparation failure - the > error string from sqlite would be propagated back up via the Context's > Error object. An allocation error, on the other hand, is simply returned as > the enum entry FSL_RC_OOM, as we can't provide more information for that > case without more allocation (which would presumably fail). > > Excellent, no surprises here.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
