On Tue, Jun 19, 2018 at 8:13 PM Sam Putman <atmanis...@gmail.com> wrote:
> >> >>> 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. > A few of the utility classes (most notably sha1 and md5) were originally copied over 1-to-1 and renamed to match the libfossil project conventions. sha1-hard and sha-3 came along after my RSI fallout, and are not included in libfossil. i have _no_ idea what the differences are between sha1 and sha1-hard, so can't comment on those. The buffer sizes differ between sha1 and sha-3, so i'm not sure whether those two could be reasonably/cleanly combined. i have to resist the temptation to go poking around in the code rabbit hole, as that almost invariably leads to days of hand pains :(. (Software development was always like a drug to me, and i am very much a recovering addict.) 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. > It "should" be trivial to port the core sha1-hard and sha-3 to libfossil - porting of sha1 and md5 was literally a copy/paste/rename job. However, the assumption that SHA1 is "the" hash is "strongly embedded" in many places in libfossil (md5 is only used in the manifest files and its usage does not need to be modified/extended). It "should" be simple to find all such places by grepping for FSL_UUID_STRLEN (defined in include/fossil-scm/fossil-hash.h), and porting all such places to support variable hashes is, AFAIK, the only critical piece needed for making libfossil compatible (again) with fossil(1). If that hurdle can be surpassed, the rest is "easy" (even the merging - it simply needs to be ported over from fossil, adapting the API to a library interface along the way). -- ----- 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
