On Fri, Feb 28, 2014 at 9:20 PM, Michael Haggerty <mhag...@alum.mit.edu> wrote: > Duy, > > The example in Documentation/technical/api-allocation-growing.txt does > it the same way as Dmitry: > > ALLOC_GROW(item, nr + 1, alloc); > item[nr++] = value you like; > > The alternative, > > nr++; > ALLOC_GROW(item, nr, alloc); > item[nr] = value you like; > > is an extra line, which is at least a small argument for the variant > shown in the docs. (Since ALLOC_GROW is a macro, it is not OK to use > "++nr" as its second argument.) Personally, I also prefer the shorter > version. The line > > item[nr++] = value > > is an easy-to-recognize idiom, and > > ALLOC_GROW(item, nr + 1, alloc); > > somehow makes it more transparent by how much more space will be needed. > > So my vote is that the patches are OK the way Dmitry wrote them (mind, I > have only read through 05/11 so far).
I'm not saying all patches should do nr++; ALLOC_GROW(item, nr, alloc); only those that do if (..) realloc...; nr++; .... should be reordered. Those changes that do item[nr++] = yyy should be kept. Anyway it's just an observation, not something that should block these patches. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
