Re: completion on brace + 4 characters doesn't work

[Vincent Lefevre <vincent@vinc17.net>]

On 2011-04-28 20:56:57 -0700, Bart Schaefer wrote:
> On Apr 29,  3:34am, Vincent Lefevre wrote:
> } Subject: Re: completion on brace + 4 characters doesn't work
> }
> } With "echo ./{abcd", valgrind complains:
> } 
> } ==13848== Source and destination overlap in strcpy(0x4027532, 0x4027533)
> } ==13848==    at 0x4C25918: strcpy (mc_replace_strmem.c:311)
> } ==13848==    by 0xD09D92C: get_comp_string (zle_tricky.c:2016)
> 
> That's this line:
> 
>    2016                 strcpy(dbeg, dbeg + len);
> 
> The code there apparently assumes a naive implementation of strcpy()
> that goes left-to-right incrementing the source and destination
> pointers in lock step.

It also assumes that the length of the string is less than len
(because the source and the destination may not overlap). The
compiler can use this fact to optimize the code. And as this is
not true, the generated code may be incorrect.

> There are instances of this assumption all
> over the place in get_comp_string().  It would not surprise me to
> find this assumption made elsewhere in the zsh sources.
> 
> Out of curiosity, does the behavior change if you crank down the
> degree of optimization (or up the of debugging) in the compiler flags
> when building?

For the test with valgrind, zsh was compiled with no optimizations,
because I configured it with the option --enable-zsh-debug.

Now, the optimization level doesn't affect the use of GCC builtins
(there's one for strcpy).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)