[PATCH 4 of 6 v6 lazy-manifest] manifest: use custom C implementation of lazymanifest

[Martin von Zweigbergk]

On Wed, Mar 11, 2015 at 9:26 PM Matt Harbison <mharbison72 at gmail.com> wrote:

> I managed to get a debug version built with various _ASSERTE(
> _CrtCheckMemory( ) ) calls sprinkled around.  It asserts in
> lazymanifest_setitem() after calling 'sprintf(dest + plen + 1 + (i * 2),
> "%02hhx", hash[i]);'.
>
> I don't see an 'hh' size prefix [1], but dropping one of the 'h' didn't
> change anything.  I got this from DebugView, tracing the relevant
> variables:
>

It seems unclear what 'hh' really means, see [1].

The '2' for the 'width' parameter is a *minimum*. I suppose if the hash was
negative, it might get sign-extended and then printed as 8 hex characters?
Does casting "hash[i]" to "unsigned char" help? But maybe it's better to
use snprintf?

Also, if the hash byte (char) get sign-extended, it seems like that would
mean that any negative byte would be result in "ff", because "ffffffxx"
gets written and most of it gets overwritten.

While writing the above, I thought that C's "char" was always signed (and
had always thought so), but according to [2], it's implementation-defined
whether it's signed or unsigned. It seems like most people's
implementations use unsigned chars, while yours uses signed chars. I
suppose that means that when your version does succeed without crashing,
your repo is likely to not verify, since the hash will be messed up. Does
it sometimes not crash? Can you check whether 'hg verify' works after
making a commit or two?

[1]
http://stackoverflow.com/questions/4586962/what-is-the-purpose-of-the-h-and-hh-modifiers-for-printf
.
[2]
http://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-by-default
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150312/2a3727dc/attachment.html>