On Mon, Mar 17, 2014 at 11:07 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
> On 03/17/2014 07:33 AM, Junio C Hamano wrote:
>> Junio C Hamano <gitster@xxxxxxxxx> writes:
>>
>>> Would it make sense to go one step further to introduce two macros
>>> to make this kind of screw-up less likely?
> potential callers that I noticed, ALLOC_GROW() was used immediately
> before making space in the array for a new element. So I suggest
> something more like
>
> +#define MOVE_DOWN(array, nr, at, count) \
> + memmove((array) + (at) + (count), \
> + (array) + (at), \
> + sizeof((array)[0]) * ((nr) - (at)))
Each time I read these, my brain (for whatever reason) interprets the
names UP and DOWN opposite of the intended meaning, which makes them
confusing. Perhaps INSERT_GAP and CLOSE_GAP would avoid such problems,
and be more consistent with Michael's proposed ALLOC_INSERT_GAP.
> +#define ALLOC_INSERT_GAP(array, nr, at, count, alloc) \
> + do { \
> + ALLOC_GROW((array), (nr) + (count), (alloc)); \
> + MOVE_DOWN((array), (nr), (at), (count)); \
> + } while (0)
>
> Also, count==1 is so frequent that this special case might deserve its
> own macro pair.
>
> I'm not inspired by these macro names, though.
>
> Michael
>
> --
> Michael Haggerty
> mhagger@xxxxxxxxxxxx
> http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html