RFA: use memcpy, not a loop

RFA: use memcpy, not a loop

[Tom Tromey]

While debugging on the python branch I ran into a couple of loops that
can be replaced with memcpy.  I find that this is easier to read and
it makes debugging a bit friendlier.

Built and tested on the compile farm (x86-64).
Ok?

Tom

2008-07-28  Tom Tromey  <tromey@redhat.com>

	* cli/cli-decode.c (lookup_cmd_1): Use memcpy.
	(lookup_cmd_composition): Likewise.

diff --git a/gdb/cli/cli-decode.c b/gdb/cli/cli-decode.c
index 6908314..5b1a7e0 100644
--- a/gdb/cli/cli-decode.c
+++ b/gdb/cli/cli-decode.c
@@ -1112,11 +1112,7 @@ lookup_cmd_1 (char **text, struct cmd_list_element *clist,
 
 
   command = (char *) alloca (len + 1);
-  for (tmp = 0; tmp < len; tmp++)
-    {
-      char x = (*text)[tmp];
-      command[tmp] = x;
-    }
+  memcpy (command, *text, len);
   command[len] = '\0';
 
   /* Look it up.  */
@@ -1468,11 +1464,7 @@ lookup_cmd_composition (char *text,
        it's length is len).  We copy this into a local temporary */
       
       command = (char *) alloca (len + 1);
-      for (tmp = 0; tmp < len; tmp++)
-      {
-        char x = text[tmp];
-        command[tmp] = x;
-      }
+      memcpy (command, text, len);
       command[len] = '\0';
       
       /* Look it up.  */

Re: RFA: use memcpy, not a loop

[Michael Snyder]

On Tue, 2008-07-29 at 13:13 -0600, Tom Tromey wrote:
> While debugging on the python branch I ran into a couple of loops that
> can be replaced with memcpy.  I find that this is easier to read and
> it makes debugging a bit friendlier.
> 
> Built and tested on the compile farm (x86-64).
> Ok?

Sure.  Looks like you can nuke "tmp" from the function too...

No need to re-submit if you decide to make that change.
But doesn't each of those functions have *two* such loops?


> 2008-07-28  Tom Tromey  <tromey@redhat.com>
> 
> 	* cli/cli-decode.c (lookup_cmd_1): Use memcpy.
> 	(lookup_cmd_composition): Likewise.
> 
> diff --git a/gdb/cli/cli-decode.c b/gdb/cli/cli-decode.c
> index 6908314..5b1a7e0 100644
> --- a/gdb/cli/cli-decode.c
> +++ b/gdb/cli/cli-decode.c
> @@ -1112,11 +1112,7 @@ lookup_cmd_1 (char **text, struct cmd_list_element *clist,
>  
> 
>    command = (char *) alloca (len + 1);
> -  for (tmp = 0; tmp < len; tmp++)
> -    {
> -      char x = (*text)[tmp];
> -      command[tmp] = x;
> -    }
> +  memcpy (command, *text, len);
>    command[len] = '\0';
>  
>    /* Look it up.  */
> @@ -1468,11 +1464,7 @@ lookup_cmd_composition (char *text,
>         it's length is len).  We copy this into a local temporary */
>        
>        command = (char *) alloca (len + 1);
> -      for (tmp = 0; tmp < len; tmp++)
> -      {
> -        char x = text[tmp];
> -        command[tmp] = x;
> -      }
> +      memcpy (command, text, len);
>        command[len] = '\0';
>        
>        /* Look it up.  */

Re: RFA: use memcpy, not a loop

[Michael Snyder]

On Tue, 2008-07-29 at 15:10 -0700, Michael Snyder wrote:
> On Tue, 2008-07-29 at 13:13 -0600, Tom Tromey wrote:
> > While debugging on the python branch I ran into a couple of loops that
> > can be replaced with memcpy.  I find that this is easier to read and
> > it makes debugging a bit friendlier.
> > 
> > Built and tested on the compile farm (x86-64).
> > Ok?
> 
> Sure.  Looks like you can nuke "tmp" from the function too...
> 
> No need to re-submit if you decide to make that change.
> But doesn't each of those functions have *two* such loops?

Oh, never mind, I see that the 2nd loop is not a simple copy.
And so it still requires 'tmp'.