On Tue, Jun 19, 2018 at 10:20 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Mon, Jun 18, 2018 at 7:18 PM Sam Putman <atmanis...@gmail.com> wrote: > >> A Capitalized pure-C struct being referred to as an object is not unheard >> of! But it did lead me down >> the wrong path. >> > > Here's my little contribution to spreading the word about OO in C: > > http://www.wanderinghorse.net/computing/papers/DoingOOInC.pdf > > :) > Looks like I've got some evening reading ahead of me! > > >> I got the sense from the docs that the hash is using the SQLite style >> versioned API, so it follows that >> the old hash code is sitting where it needs to. >> >> Does this amount to following the style of that file for another similar >> file in fossil(1)? >> > > i'm not clear what you mean :|. > > I'm sure that could have been more clear. Did some poking around between fossil and libfossil, it looks like they both have a sha-1.c, the difference starts with the copyright, 2006 vs 2013. A cursory scan suggests that the ~200 line difference is more tests, and some framework code that presumably libfossil doesn't need. fossil also has sha1-hard.c (let's ignore this for now?) and sha3.c. I haven't yet found where in libfossil sha-1.c is called, and what the substantive differences are between the two. What I'm wondering is, can the wrapper for sha-1.c be rewritten to also wrap sha-3? Possibly sha1-hard as well, if it's on a critical path. I know there's some wrinkles around how fossil picks a sha that allowed for the transition, I'm content with being able to wield those sha functions in a fossil context at a fairly low level, for now.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
