<div dir="ltr">I'll send a patch soon. Matt, let me know if it helps you.<br></div><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 8:33 AM Martin von Zweigbergk <<a href="mailto:martinvonz@google.com">martinvonz@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">On Wed, Mar 11, 2015 at 10:53 PM Martin von Zweigbergk <<a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote">On Wed, Mar 11, 2015 at 9:26 PM Matt Harbison <<a href="mailto:mharbison72@gmail.com" target="_blank">mharbison72@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I managed to get a debug version built with various _ASSERTE(<br>
_CrtCheckMemory( ) ) calls sprinkled around.  It asserts in<br>
lazymanifest_setitem() after calling 'sprintf(dest + plen + 1 + (i * 2),<br>
"%02hhx", hash[i]);'.<br>
<br>
I don't see an 'hh' size prefix [1], but dropping one of the 'h' didn't<br>
change anything.  I got this from DebugView, tracing the relevant<br>
variables:<br></blockquote><div><br></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>It seems unclear what 'hh' really means, see [1].</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>[1] <span style="font-size:13.1999998092651px"><a href="http://stackoverflow.com/questions/4586962/what-is-the-purpose-of-the-h-and-hh-modifiers-for-printf" target="_blank">http://stackoverflow.com/<u></u>q<u></u>uestions/4586962/what-is-the-<u></u>p<u></u>urpose-of-the-h-and-hh-<u></u>modifie<u></u>rs-for-printf</a>.</span></div><div><div style="font-size:13.1999998092651px">[2] <a href="http://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-by-default" target="_blank">http://stackoverflow.com/<u></u>quest<u></u>ions/2054939/is-char-<u></u>signed-<u></u>or-unsigned-by-default</a></div></div><div style="font-size:13.1999998092651px"><br></div></div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>It turns out char is signed on my system too, so I suppose what saves me is that my sprintf does treat 'hh' by treating the parameter as char width, while it seems like your sprintf doesn't. So, I think dropping the "hh" and sticking a cast to unsigned char in there is a good solution. Augie, what do you think?</div><div><br></div></div></div></blockquote></div>