Re: [Xen-devel] [PATCH v2] Sanity check xsave area when migrating or restoring from older Xen verions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.10.14 at 17:40, <dkoch@xxxxxxxxxxx> wrote:
> On Mon, 20 Oct 2014 16:28:47 +0100
> Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 20.10.14 at 14:54, <dkoch@xxxxxxxxxxx> wrote:
>> > On Sat, 18 Oct 2014 00:36:28 +0100
>> > Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> >> On 17/10/2014 18:11, Don Koch wrote:
>> >> > +        for (int i = size; i < desc->length; i++)
>> >> 
>> >> Style
>> > 
>> > Is not really defined for "for". I checked the CODING_STYLE file and it 
> only
>> > defines style for "if" and "while".
>> 
>> Did you skip the "such as" in the section dealing with them?
> 
> Still not explicitly mentioned.

Why are you insisting on everything being explicitly mentioned. I
agree there are areas in the document that could do with
improvement, but adding "for" alongside "if" and "while" isn't one
of them imo.

> I would have assumed they needed
> spaces if it weren't for all the counterexamples.

Yes, there are counterexamples, but largely due to the mixture of
Xen and Linux style files (and sometimes within a file). This is
unfortunate, but there are sufficiently many good examples in
case you can't derive the general rules from the examples given
in ./CODING_STYLE.

>> > I found more examples of "for" statements
>> > with no spaces inside the parens; so, I went with that. Will fix.
>> 
>> It's not just about the missing spaces. You also shouldn't declare
>> variables inside the for() statement.
> 
> This, too, wasn't mentioned at all in CODING_STYLES, but, of course, will
> fix in my code (I had wondered about that, too).

But I don't think you'll find many bad examples throughout xen/ for
this one.

>> > Do you want me to update the CODING_STYLES file, too? (In a separate patch,
>> > of course.)
>> 
>> As hinted at -  the document is sufficient as is afaict.
> 
> As hinted at - the document is lacking; too much is impliedn (at least, IMO).

As said above - useful improvements to the document are welcome,
but adding stuff that is intentional to be implied doesn't fall in this
category afaic. The document should remain reasonably short, or
else we risk people not reading enough of it.

Jan


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