On Wed, Aug 22, 2018 at 08:42:20AM -0400, Paul Smith wrote:
> On Tue, 2018-08-21 at 23:03 -0400, Jeff King wrote:
> > static inline int hashcmp(const unsigned char *sha1, const unsigned
> > char *sha2)
> > {
> > + assert(the_hash_algo->rawsz == 20);
> > return memcmp(sha1, sha2, the_hash_algo->rawsz);
> > }
>
> I'm not familiar with Git code, but for most environments assert() is a
> macro which is compiled out when built for "release mode" (whatever
> that might mean). If that's the case for Git too, then relying on
> assert() to provide a side-effect (even an optimizer hint side-effect)
> won't work and this will actually get slower when built for "release
> mode".
>
> Just a thought...
We don't have such a "release mode" in Git, though of course people may
pass -DNDEBUG to the compiler if they want.
However, to me how we spell the assert is mostly orthogonal to the
discussion. We can do "if (...) BUG(...)" to get a guaranteed-present
conditional. The bigger questions are:
- are we OK with such an assertion; and
- does the assertion still give us the desired behavior when we add in
a branch for rawsz==32?
And I think the answers for those are both "probably not".
-Peff