# [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()

7 messages from 2019-09-19 to 2019-09-26. Participants: René Scharfe, Jeff King, Johannes Schindelin, Derrick Stolee, SZEDER Gábor, Philip Oakley.
Thread: https://gitlist.dev/t/51886

## René Scharfe, 2019-09-19 20:48

Subject: [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()
Message-ID: <d5eef24a-faa8-d6f3-c9e5-f13dc40219d4@web.de>
URL: https://gitlist.dev/e/d5eef24a-faa8-d6f3-c9e5-f13dc40219d4%40web.de

```
Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
same for moving them backwards in an array with potential overlap.  The
result is shorter and safer, as it infers the element type automatically
and does a (very) basic type compatibility check for its first two
arguments.

These cases were missed by Coccinelle and contrib/coccinelle/array.cocci
because the type of the elements is "const char *", not "char *", and
the rules in the semantic patch cautiously insist on the sizeof operator
being used on exactly the same type to avoid generating transformations
that introduce subtle bugs into tricky code.

Signed-off-by: René Scharfe <l.s.r@web.de>
---
 git.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/git.c b/git.c
index c1ee7124ed..ce6ab0ece2 100644
--- a/git.c
+++ b/git.c
@@ -369,8 +369,7 @@ static int handle_alias(int *argcp, const char ***argv)
 			die(_("alias '%s' changes environment variables.\n"
 			      "You can use '!git' in the alias to do this"),
 			    alias_command);
-		memmove(new_argv - option_count, new_argv,
-				count * sizeof(char *));
+		MOVE_ARRAY(new_argv - option_count, new_argv, count);
 		new_argv -= option_count;

 		if (count < 1)
@@ -385,7 +384,7 @@ static int handle_alias(int *argcp, const char ***argv)

 		REALLOC_ARRAY(new_argv, count + *argcp);
 		/* insert after command name */
-		memcpy(new_argv + count, *argv + 1, sizeof(char *) * *argcp);
+		COPY_ARRAY(new_argv + count, *argv + 1, *argcp);

 		trace2_cmd_alias(alias_command, new_argv);
 		trace2_cmd_list_config();
--
2.23.0

```

## Jeff King, 2019-09-23 22:27

Subject: Re: [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()
Message-ID: <20190923222659.GA22645@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20190923222659.GA22645%40sigill.intra.peff.net
In-Reply-To: <d5eef24a-faa8-d6f3-c9e5-f13dc40219d4@web.de>

```
On Thu, Sep 19, 2019 at 10:48:30PM +0200, René Scharfe wrote:

> Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
> same for moving them backwards in an array with potential overlap.  The
> result is shorter and safer, as it infers the element type automatically
> and does a (very) basic type compatibility check for its first two
> arguments.
> 
> These cases were missed by Coccinelle and contrib/coccinelle/array.cocci
> because the type of the elements is "const char *", not "char *", and
> the rules in the semantic patch cautiously insist on the sizeof operator
> being used on exactly the same type to avoid generating transformations
> that introduce subtle bugs into tricky code.

Another good reason to use "sizeof(var)" instead of sizeof(type)". :)

The patch looks good.

-Peff

```

## Johannes Schindelin, 2019-09-26 13:22

Subject: sizeof(var) vs sizeof(type), was Re: [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()
Message-ID: <nycvar.QRO.7.76.6.1909261521380.15067@tvgsbejvaqbjf.bet>
URL: https://gitlist.dev/e/nycvar.QRO.7.76.6.1909261521380.15067%40tvgsbejvaqbjf.bet
In-Reply-To: <20190923222659.GA22645@sigill.intra.peff.net>

```
Hi Peff,

On Mon, 23 Sep 2019, Jeff King wrote:

> On Thu, Sep 19, 2019 at 10:48:30PM +0200, René Scharfe wrote:
>
> > Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
> > same for moving them backwards in an array with potential overlap.  The
> > result is shorter and safer, as it infers the element type automatically
> > and does a (very) basic type compatibility check for its first two
> > arguments.
> >
> > These cases were missed by Coccinelle and contrib/coccinelle/array.cocci
> > because the type of the elements is "const char *", not "char *", and
> > the rules in the semantic patch cautiously insist on the sizeof operator
> > being used on exactly the same type to avoid generating transformations
> > that introduce subtle bugs into tricky code.
>
> Another good reason to use "sizeof(var)" instead of sizeof(type)". :)

That is indeed a very good reason, in addition to getting the type right
automatically (by virtue of letting the compiler pick it).

Should we make this an explicit guideline in our documentation?

Ciao,
Dscho

```

## Derrick Stolee, 2019-09-26 13:36

Subject: Re: sizeof(var) vs sizeof(type), was Re: [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()
Message-ID: <b79f52f7-4a7e-f7cd-ed8a-cb6cfbadd7b2@gmail.com>
URL: https://gitlist.dev/e/b79f52f7-4a7e-f7cd-ed8a-cb6cfbadd7b2%40gmail.com
In-Reply-To: <nycvar.QRO.7.76.6.1909261521380.15067@tvgsbejvaqbjf.bet>

```
On 9/26/2019 9:22 AM, Johannes Schindelin wrote:
> Hi Peff,
> 
> On Mon, 23 Sep 2019, Jeff King wrote:
> 
>> On Thu, Sep 19, 2019 at 10:48:30PM +0200, René Scharfe wrote:
>>
>>> Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
>>> same for moving them backwards in an array with potential overlap.  The
>>> result is shorter and safer, as it infers the element type automatically
>>> and does a (very) basic type compatibility check for its first two
>>> arguments.
>>>
>>> These cases were missed by Coccinelle and contrib/coccinelle/array.cocci
>>> because the type of the elements is "const char *", not "char *", and
>>> the rules in the semantic patch cautiously insist on the sizeof operator
>>> being used on exactly the same type to avoid generating transformations
>>> that introduce subtle bugs into tricky code.
>>
>> Another good reason to use "sizeof(var)" instead of sizeof(type)". :)
> 
> That is indeed a very good reason, in addition to getting the type right
> automatically (by virtue of letting the compiler pick it).
> 
> Should we make this an explicit guideline in our documentation?

Better yet: can we create a Coccinelle script to fix it automatically?

-Stolee


```

## SZEDER Gábor, 2019-09-26 13:43

Subject: Re: sizeof(var) vs sizeof(type), was Re: [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()
Message-ID: <20190926134341.GG2637@szeder.dev>
URL: https://gitlist.dev/e/20190926134341.GG2637%40szeder.dev
In-Reply-To: <b79f52f7-4a7e-f7cd-ed8a-cb6cfbadd7b2@gmail.com>

```
On Thu, Sep 26, 2019 at 09:36:44AM -0400, Derrick Stolee wrote:
> On 9/26/2019 9:22 AM, Johannes Schindelin wrote:
> > Hi Peff,
> > 
> > On Mon, 23 Sep 2019, Jeff King wrote:
> > 
> >> On Thu, Sep 19, 2019 at 10:48:30PM +0200, René Scharfe wrote:
> >>
> >>> Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
> >>> same for moving them backwards in an array with potential overlap.  The
> >>> result is shorter and safer, as it infers the element type automatically
> >>> and does a (very) basic type compatibility check for its first two
> >>> arguments.
> >>>
> >>> These cases were missed by Coccinelle and contrib/coccinelle/array.cocci
> >>> because the type of the elements is "const char *", not "char *", and
> >>> the rules in the semantic patch cautiously insist on the sizeof operator
> >>> being used on exactly the same type to avoid generating transformations
> >>> that introduce subtle bugs into tricky code.
> >>
> >> Another good reason to use "sizeof(var)" instead of sizeof(type)". :)
> > 
> > That is indeed a very good reason, in addition to getting the type right
> > automatically (by virtue of letting the compiler pick it).
> > 
> > Should we make this an explicit guideline in our documentation?
> 
> Better yet: can we create a Coccinelle script to fix it automatically?

I've already done that well over a year ago :)  But remember not being
quite satisfied with something (no idea what it was anymore) and left
it on the backburner.

Will dig it out and have a look as time permits.


```

## Philip Oakley, 2019-09-26 15:24

Subject: Re: sizeof(var) vs sizeof(type), was Re: [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()
Message-ID: <7bbcf6fa-e36d-4a1e-86e1-437e9e92dab7@iee.email>
URL: https://gitlist.dev/e/7bbcf6fa-e36d-4a1e-86e1-437e9e92dab7%40iee.email
In-Reply-To: <b79f52f7-4a7e-f7cd-ed8a-cb6cfbadd7b2@gmail.com>

```
On 26/09/2019 14:36, Derrick Stolee wrote:
>>> Another good reason to use "sizeof(var)" instead of sizeof(type)". :)
>> That is indeed a very good reason, in addition to getting the type right
>> automatically (by virtue of letting the compiler pick it).
>>
>> Should we make this an explicit guideline in our documentation?
> Better yet: can we create a Coccinelle script to fix it automatically?
>
> -Stolee
>
How about 'Both'. We can't assume all contributors have Coccinelle on 
their OS/system.

Philip

```

## Derrick Stolee, 2019-09-26 16:16

Subject: Re: sizeof(var) vs sizeof(type), was Re: [PATCH] git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()
Message-ID: <6ecafde8-cd1c-9457-4102-b73304a122fd@gmail.com>
URL: https://gitlist.dev/e/6ecafde8-cd1c-9457-4102-b73304a122fd%40gmail.com
In-Reply-To: <7bbcf6fa-e36d-4a1e-86e1-437e9e92dab7@iee.email>

```
On 9/26/2019 11:24 AM, Philip Oakley wrote:
> On 26/09/2019 14:36, Derrick Stolee wrote:
>>>> Another good reason to use "sizeof(var)" instead of sizeof(type)". :)
>>> That is indeed a very good reason, in addition to getting the type right
>>> automatically (by virtue of letting the compiler pick it).
>>>
>>> Should we make this an explicit guideline in our documentation?
>> Better yet: can we create a Coccinelle script to fix it automatically?
>>
>> -Stolee
>>
> How about 'Both'. We can't assume all contributors have Coccinelle on their OS/system.

Both is best, but I find static checkers to be more reliable than
updating documentation. For that reason, I would prioritize the
Coccinelle script over adding another bullet point to the style
guide.

The PR builds for GitGitGadget run ci/run-static-analysis.sh as a check
(see the StaticAnalysis job in [1] for an example). That provides a free
way to get feedback for users without Coccinelle.

[1] https://dev.azure.com/gitgitgadget/git/_build/results?buildId=16864&view=logs

Thanks,
-Stolee

```
