Michael Haggerty writes:
> I had recently been thinking along the same lines. In many of the
> 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
On Mon, Mar 17, 2014 at 03:06:02PM -0400, Eric Sunshine wrote:
> On Mon, Mar 17, 2014 at 11:07 AM, Michael Haggerty
> wrote:
> > On 03/17/2014 07:33 AM, Junio C Hamano wrote:
> >> Junio C Hamano writes:
> >>
> >>> Would it make sense to go one step further to introduce two macros
> >>> to make
On Mon, Mar 17, 2014 at 11:07 AM, Michael Haggerty wrote:
> On 03/17/2014 07:33 AM, Junio C Hamano wrote:
>> Junio C Hamano 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_GR
On 03/17/2014 07:33 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Would it make sense to go one step further to introduce two macros
>> to make this kind of screw-up less likely?
>> ...
>> After letting my eyes coast over hits from "git grep memmove", there
>> do seem to be some places
Junio C Hamano writes:
> Would it make sense to go one step further to introduce two macros
> to make this kind of screw-up less likely?
> ...
> After letting my eyes coast over hits from "git grep memmove", there
> do seem to be some places that these would help readability, but not
> very many.
Jeff King writes:
> On Sat, Mar 15, 2014 at 05:05:29PM +0100, Thomas Rast wrote:
>
>> > diff --git a/builtin/mv.c b/builtin/mv.c
>> > index f99c91e..b20cd95 100644
>> > --- a/builtin/mv.c
>> > +++ b/builtin/mv.c
>> > @@ -230,6 +230,11 @@ int cmd_mv(int argc, const char **argv, const char
>> > *p
On Sat, Mar 15, 2014 at 05:05:29PM +0100, Thomas Rast wrote:
> > diff --git a/builtin/mv.c b/builtin/mv.c
> > index f99c91e..b20cd95 100644
> > --- a/builtin/mv.c
> > +++ b/builtin/mv.c
> > @@ -230,6 +230,11 @@ int cmd_mv(int argc, const char **argv, const char
> > *prefix)
> >
"brian m. carlson" writes:
> We shrink the source and destination arrays, but not the modes or
> submodule_gitfile arrays, resulting in potentially mismatched data. Shrink
> all the arrays at the same time to prevent this.
>
> Signed-off-by: brian m. carlson
> ---
> builtin/mv.c | 5 +
> 1
On Tue, Mar 11, 2014 at 02:45:59PM -0700, Junio C Hamano wrote:
> Thanks. Neither this nor John's seems to describe the user-visible
> way to trigger the symptom. Can we have tests for them?
I'll try to get to writing some test today or tomorrow. I just noticed
the bugginess by looking at the c
"brian m. carlson" writes:
> We shrink the source and destination arrays, but not the modes or
> submodule_gitfile arrays, resulting in potentially mismatched data. Shrink
> all the arrays at the same time to prevent this.
>
> Signed-off-by: brian m. carlson
> ---
> builtin/mv.c | 5 +
> 1
On Mon, Mar 10, 2014 at 09:56:03PM -0400, Jeff King wrote:
> On Sat, Mar 08, 2014 at 07:21:39PM +, brian m. carlson wrote:
>
> > We shrink the source and destination arrays, but not the modes or
> > submodule_gitfile arrays, resulting in potentially mismatched data. Shrink
> > all the arrays
On Sat, Mar 08, 2014 at 07:21:39PM +, brian m. carlson wrote:
> We shrink the source and destination arrays, but not the modes or
> submodule_gitfile arrays, resulting in potentially mismatched data. Shrink
> all the arrays at the same time to prevent this.
>
> Signed-off-by: brian m. carlso
12 matches
Mail list logo
