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. 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). -- ----- 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
