Re: [Xen-devel] differing opinions between maintainers vs patch acks

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: differing opinions between maintainers vs patch acks"):
> On 04.05.17 at 14:44, <ian.jackson@xxxxxxxxxxxxx> wrote:
> > Well, at one level I agree with Andrew on at least the 1*1 and 0*8
> > question.  These seem clearer to me as they state the programmer's
> > intent as well as merely the effect.  I found Jan's response hard to
> > understand; there doesn't actually seem to be a counterargument.
> 
> My counterargument was that 0*8 clearly equals 0 for anyone
> knowledgeable enough to read this code, as does 1*8 = 8.
> Anyway, seeing that you agree with Andrew, I'll go make the
> change, no matter that I think it doesn't belong here (besides
> being pointless).

Thanks for being flexible.  I continue to think that in this case
Andrew ought to be showing flexibility.  Although of course if you
have been convinced (perhaps about the readability to others), that is
good to acknowledge even if implicitly.


I feel motivated to explain why I don't find your counterargument
convincing.  The reason why `0*8' is better than `0' (or complete
absence of an offset), and `1*8' is better than `8', is that it better
explains _why_ the value of zero was chosen.  Ie, where the value
comes from.

In particular `0*8' mentions 8 (the stride), whereas `0' doesn't
mention 8 at all and so could be some other kind of magic number; and
complete lack of an offset doesn't mention that in some underlying
sense is an offset which happens to be zero slots of size 8.

Ie, while `0*8' clearly implies `0', since everyone knows that 0*8 is
zero, `0' does not necessarily imply `0*8'.

A reader who sees this has to look slightly further to the surrounding
context etc., and expend slightly more cognitive effort, to see that
this code is equivalent to the `2*8' etc. earlier.

I don't know if this interjection helps at all.  Maybe I should just
let the conversation end now...

> >  I
> > suspect if I thought about it enough I would agree with Andrew about
> > the labels too.
> 
> Along those lines I'd then also go make the change here, if only
> there was an alternative naming of the label tags that I can at
> least live with; the suggestion to simply divide the numbers by 8
> is, as expressed, not something I consider reasonable. So I'll
> make my changing of those label tags dependent one someone
> coming forward with a naming scheme which is both better than
> what is there and better then using simple stack slot numbers
> without it being clear that stack slots are being meant.

I'm not sure why `blah_blah_stackslot3' etc. is not suitable.  But I
don't feel I have thought about this particular bikeshed enough to
have an opinion about the right shade of green.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel