[m-rev.] for post-commit review: fix mantis bug #367

[Peter Wang]

On Fri, 05 Dec 2014 17:43:38 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Fri, 5 Dec 2014 16:11:09 +1100, Peter Wang <novalazy at gmail.com> wrote:
> 
> > On Wed, 03 Dec 2014 18:20:15 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > Fix Mantis bug #367.
> > 
> > Please avoid using only a bug number for commit summary.
> 
> It is the git limit on the commit description. It is hard enough to describe
> the change itself in 50 characters; including the bug number makes it
> almost impossible. So I usually pick one or the other, not both.
> The meat of the diff explains the diff anyway, and is not squeezed.

You can go (much) longer; even the Linux kernel specifies 75 chars.
If you have to choose, I suggest that the descriptive summary is more
useful when browsing the history (gitk, git log --oneline, github, etc.)
A bug number number in the main body text will still by found when
searching, e.g. with git log --grep.

> Or are you worried about the compiler moving Mid < Hi to AFTER
> the lookup? I am pretty sure the compiler is not allowed to do that,

Yes, that is the worry.  The "strict commutative" operational semantics
allows it, does it not?

Peter