On Tue, Jun 19, 2018 at 11:28 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> 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'm fairly sure the various hashes need to operate separately. It also sounds like the fossil(1) side of this is a matter of updating libfossil with the latest versions. > 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). > > That kind of breadcrumb (FSL_UUID_STRLEN) is really helpful, thanks. Don't know when or even if I might, but I'm warming to the idea of trying it.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
