* completion on brace + 4 characters doesn't work @ 2011-04-28 11:11 Vincent Lefevre 2011-04-28 15:12 ` Bart Schaefer 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-04-28 11:11 UTC (permalink / raw) To: zsh-workers Hi, I've just found the following problem: $ zsh-beta -f xvii% echo $ZSH_VERSION 4.3.11-dev-2-cvs0421 xvii% ls -a . .. abcdef xvii% echo ./{abcd Here when I hit [Tab], nothing is completed. However, the completion works if I remove the d. -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-28 11:11 completion on brace + 4 characters doesn't work Vincent Lefevre @ 2011-04-28 15:12 ` Bart Schaefer 2011-04-28 22:27 ` Vincent Lefevre 0 siblings, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2011-04-28 15:12 UTC (permalink / raw) To: zsh-workers On Apr 28, 1:11pm, Vincent Lefevre wrote: } } $ zsh-beta -f } xvii% echo $ZSH_VERSION } 4.3.11-dev-2-cvs0421 ZSH_PATCHLEVEL is more useful now because it doesn't include any local modifications (like "-cvs0421") that are meaningless to those of us who aren't involved with whatever precompiled package one may have installed. } xvii% ls -a } . .. abcdef } xvii% echo ./{abcd } } Here when I hit [Tab], nothing is completed. However, the completion } works if I remove the d. If you're starting from zsh -f then this is the old compctl which is pretty much unmaintained at this point. However, I'm not able to reproduce this problem on my CentOS 4 box: torch% echo $ZSH_VERSION $ZSH_PATCHLEVEL 4.3.11-dev-2 1.5265 torch% ls -a . .. abcdef torch% echo ./{abcdef, ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-28 15:12 ` Bart Schaefer @ 2011-04-28 22:27 ` Vincent Lefevre 2011-04-29 0:31 ` Vincent Lefevre 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-04-28 22:27 UTC (permalink / raw) To: zsh-workers On 2011-04-28 08:12:40 -0700, Bart Schaefer wrote: > On Apr 28, 1:11pm, Vincent Lefevre wrote: > } > } $ zsh-beta -f > } xvii% echo $ZSH_VERSION > } 4.3.11-dev-2-cvs0421 > > ZSH_PATCHLEVEL is more useful now because it doesn't include any local > modifications (like "-cvs0421") that are meaningless to those of us > who aren't involved with whatever precompiled package one may have > installed. OK: 1.5256 under Debian. But the same problem occurs with Debian's 4.3.11 zsh package. > } xvii% ls -a > } . .. abcdef > } xvii% echo ./{abcd > } > } Here when I hit [Tab], nothing is completed. However, the completion > } works if I remove the d. > > If you're starting from zsh -f then this is the old compctl which is > pretty much unmaintained at this point. Same problem with: autoload -U compinit compinit > However, I'm not able to reproduce this problem on my CentOS 4 box: > > torch% echo $ZSH_VERSION $ZSH_PATCHLEVEL > 4.3.11-dev-2 1.5265 > torch% ls -a > . .. abcdef > torch% echo ./{abcdef, I can't reproduce the problem either under Mac OS X. And I can't reproduce it under Red Hat with the official zsh 4.3.10. I've looked at Debian's patches for the zsh package, but I don't see anything related to the problem here. -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-28 22:27 ` Vincent Lefevre @ 2011-04-29 0:31 ` Vincent Lefevre 2011-04-29 0:59 ` Vincent Lefevre 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-04-29 0:31 UTC (permalink / raw) To: zsh-workers On 2011-04-29 00:27:54 +0200, Vincent Lefevre wrote: > I've looked at Debian's patches for the zsh package, but I don't > see anything related to the problem here. I have recompiled the official zsh 4.3.11 under Debian, and have the same problem with it. -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 0:31 ` Vincent Lefevre @ 2011-04-29 0:59 ` Vincent Lefevre 2011-04-29 1:34 ` Vincent Lefevre 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-04-29 0:59 UTC (permalink / raw) To: zsh-workers On 2011-04-29 02:31:49 +0200, Vincent Lefevre wrote: > On 2011-04-29 00:27:54 +0200, Vincent Lefevre wrote: > > I've looked at Debian's patches for the zsh package, but I don't > > see anything related to the problem here. > > I have recompiled the official zsh 4.3.11 under Debian, and have the > same problem with it. I've done a strace in both cases. With "echo ./{abc[TAB]", I get: [...] 16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fff7a4b17f0) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual.zwc", 0x7fff7a4b1760) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", 0x7fff7a4b16d0) = -1 ENOENT (No such file or directory) 16059 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", R_OK) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fff7a4b17f0) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual.zwc", 0x7fff7a4b1760) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", {st_mode=S_IFREG|0644, st_size=858, ...}) = 0 16059 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", R_OK) = 0 16059 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", O_RDONLY|O_NOCTTY) = 3 16059 lseek(3, 0, SEEK_END) = 858 16059 lseek(3, 0, SEEK_SET) = 0 16059 read(3, "#autoload\n\n# Test if $1 has glob"..., 858) = 858 16059 close(3) = 0 [...] 16059 open("/dev/null", O_WRONLY|O_CREAT|O_NOCTTY|O_TRUNC, 0666) = 3 16059 fcntl(2, F_DUPFD, 10) = 12 16059 close(2) = 0 16059 dup2(3, 2) = 2 16059 close(3) = 0 16059 open("./", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 16059 getdents(3, /* 3 entries */, 32768) = 80 16059 getdents(3, /* 0 entries */, 32768) = 0 16059 close(3) = 0 16059 dup2(12, 2) = 2 16059 close(12) = 0 [...] 16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fff7a4b0240) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_list_files.zwc", 0x7fff7a4b01b0) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_list_files", 0x7fff7a4b0120) = -1 ENOENT (No such file or directory) 16059 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_list_files", R_OK) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fff7a4b0240) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files.zwc", 0x7fff7a4b01b0) = -1 ENOENT (No such file or directory) 16059 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files", {st_mode=S_IFREG|0644, st_size=1420, ...}) = 0 16059 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files", R_OK) = 0 16059 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_list_files", O_RDONLY|O_NOCTTY) = 3 16059 lseek(3, 0, SEEK_END) = 1420 16059 lseek(3, 0, SEEK_SET) = 0 16059 read(3, "#autoload\n\n# Helper function for"..., 1420) = 1420 16059 close(3) = 0 [...] 16059 lstat("./abcdef", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 16059 stat("./abcdef", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 [...] With "echo ./{abcd[TAB]", I get: [...] 16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fffd1930340) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual.zwc", 0x7fffd19302b0) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", 0x7fffd1930220) = -1 ENOENT (No such file or directory) 16063 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_have_glob_qual", R_OK) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fffd1930340) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual.zwc", 0x7fffd19302b0) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", {st_mode=S_IFREG|0644, st_size=858, ...}) = 0 16063 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", R_OK) = 0 16063 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_have_glob_qual", O_RDONLY|O_NOCTTY) = 3 16063 lseek(3, 0, SEEK_END) = 858 16063 lseek(3, 0, SEEK_SET) = 0 16063 read(3, "#autoload\n\n# Test if $1 has glob"..., 858) = 858 16063 close(3) = 0 [...] 16063 open("/dev/null", O_WRONLY|O_CREAT|O_NOCTTY|O_TRUNC, 0666) = 3 16063 fcntl(2, F_DUPFD, 10) = 12 16063 close(2) = 0 16063 dup2(3, 2) = 2 16063 close(3) = 0 16063 open("./", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 16063 getdents(3, /* 3 entries */, 32768) = 80 16063 getdents(3, /* 0 entries */, 32768) = 0 16063 close(3) = 0 16063 dup2(12, 2) = 2 16063 close(12) = 0 [...] 16063 access("./acdd", F_OK) = -1 ENOENT (No such file or directory) [...] 16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions.zwc", 0x7fffd193ab60) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_ignored.zwc", 0x7fffd193aad0) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/site-functions/_ignored", 0x7fffd193aa40) = -1 ENOENT (No such file or directory) 16063 access("/home/vlefevre/zsh-test/share/zsh/site-functions/_ignored", R_OK) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions.zwc", 0x7fffd193ab60) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored.zwc", 0x7fffd193aad0) = -1 ENOENT (No such file or directory) 16063 stat("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored", {st_mode=S_IFREG|0644, st_size=1647, ...}) = 0 16063 access("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored", R_OK) = 0 16063 open("/home/vlefevre/zsh-test/share/zsh/4.3.11/functions/_ignored", O_RDONLY|O_NOCTTY) = 3 16063 lseek(3, 0, SEEK_END) = 1647 16063 lseek(3, 0, SEEK_SET) = 0 16063 read(3, "#autoload\n\n# Use ignored matches"..., 1647) = 1647 16063 close(3) = 0 [...] The question is why this access("./acdd", F_OK) in the latter case? -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 0:59 ` Vincent Lefevre @ 2011-04-29 1:34 ` Vincent Lefevre 2011-04-29 3:56 ` Bart Schaefer 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-04-29 1:34 UTC (permalink / raw) To: zsh-workers 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) ==13848== by 0xD098D9C: docomplete (zle_tricky.c:659) ==13848== by 0xD098126: expandorcomplete (zle_tricky.c:315) ==13848== by 0xD097D0B: completecall (zle_tricky.c:208) ==13848== by 0xD0862E0: execzlefunc (zle_main.c:1311) ==13848== by 0xD085787: zlecore (zle_main.c:1058) ==13848== by 0xD085EAB: zleread (zle_main.c:1219) ==13848== by 0xD0888F3: zle_main_entry (zle_main.c:1874) ==13848== by 0x44B83F: zleentry (init.c:1374) ==13848== by 0x44C2B4: inputline (input.c:281) ==13848== by 0x44C12B: ingetc (input.c:217) -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 1:34 ` Vincent Lefevre @ 2011-04-29 3:56 ` Bart Schaefer 2011-04-29 8:44 ` Vincent Lefevre 0 siblings, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2011-04-29 3:56 UTC (permalink / raw) To: zsh-workers 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. 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? Looking at the patch below, I'm puzzled by the *dbeg = '{' assignments -- they're to restore the string after a '\0' was plugged into it temporarily, but isn't *dbeg immediately clobbered by whatever is at *(dbeg+len) ? Why bother restoring it? I suppose len == 0 may be possible ... Index: Src/Zle/zle_tricky.c =================================================================== RCS file: /extra/cvsroot/zsh/zsh-4.0/Src/Zle/zle_tricky.c,v retrieving revision 1.30 diff -c -r1.30 zle_tricky.c --- zle_tricky.c 21 Dec 2010 16:41:16 -0000 1.30 +++ zle_tricky.c 29 Apr 2011 03:45:13 -0000 @@ -1899,7 +1899,7 @@ *dbeg = '{'; i -= len; boffs -= len; - strcpy(dbeg, dbeg + len); + memmove(dbeg, dbeg + len, 1+strlen(dbeg+len)); dp -= len; } bbeg = lastp = p; @@ -1948,7 +1948,7 @@ *dbeg = '{'; i -= len; boffs -= len; - strcpy(dbeg, dbeg + len); + memmove(dbeg, dbeg + len, 1+strlen(dbeg+len)); dp -= len; } bbeg = NULL; @@ -2013,7 +2013,7 @@ new->qpos = strlen(quotename(predup, NULL)); *dbeg = '{'; boffs -= len; - strcpy(dbeg, dbeg + len); + memmove(dbeg, dbeg + len, 1+strlen(dbeg+len)); } if (brend) { Brinfo bp, prev = NULL; @@ -2026,7 +2026,7 @@ l = bp->qpos; bp->pos = strlen(predup + p + l); bp->qpos = strlen(quotename(predup + p + l, NULL)); - strcpy(predup + p, predup + p + l); + memmove(predup + p, predup + p + l, 1+bp->pos); } } if (hascom) { ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 3:56 ` Bart Schaefer @ 2011-04-29 8:44 ` Vincent Lefevre 2011-04-29 11:15 ` Vincent Lefevre 2011-04-29 14:20 ` Bart Schaefer 0 siblings, 2 replies; 14+ messages in thread From: Vincent Lefevre @ 2011-04-29 8:44 UTC (permalink / raw) To: zsh-workers 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 8:44 ` Vincent Lefevre @ 2011-04-29 11:15 ` Vincent Lefevre 2011-05-04 9:33 ` Vincent Lefevre 2011-04-29 14:20 ` Bart Schaefer 1 sibling, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-04-29 11:15 UTC (permalink / raw) To: zsh-workers On 2011-04-29 10:44:44 +0200, Vincent Lefevre wrote: > On 2011-04-28 20:56:57 -0700, Bart Schaefer wrote: > > 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). In fact, the behavior comes from glibc on x86_64. It can be reproduced with: #include <stdio.h> #include <string.h> int main (void) { static char s[] = "{abcd"; volatile int len = 1; printf ("s = %s\n", s); strcpy (s, s + len); printf ("s = %s\n", s); return 0; } and gcc -fno-builtin (the strcpy builtin was not used anyway). According to gdb, the source in eglibc-2.11.2 is sysdeps/x86_64/multiarch/strcpy.S (strcpy with SSSE3). It can load 16 bytes at a time, and it uses special code on these 16 bytes (I'm not sure, but it seems to have code for each length). -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 11:15 ` Vincent Lefevre @ 2011-05-04 9:33 ` Vincent Lefevre 0 siblings, 0 replies; 14+ messages in thread From: Vincent Lefevre @ 2011-05-04 9:33 UTC (permalink / raw) To: zsh-workers On 2011-04-29 13:15:58 +0200, Vincent Lefevre wrote: > In fact, the behavior comes from glibc on x86_64. It can be > reproduced with: > > #include <stdio.h> > #include <string.h> > > int main (void) > { > static char s[] = "{abcd"; > volatile int len = 1; > > printf ("s = %s\n", s); > strcpy (s, s + len); > printf ("s = %s\n", s); > return 0; > } > > and gcc -fno-builtin (the strcpy builtin was not used anyway). > > According to gdb, the source in eglibc-2.11.2 is > sysdeps/x86_64/multiarch/strcpy.S (strcpy with SSSE3). It can load > 16 bytes at a time, and it uses special code on these 16 bytes (I'm > not sure, but it seems to have code for each length). FYI, this new strcpy code breaks many applications: http://sourceware.org/bugzilla/show_bug.cgi?id=12518 -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 8:44 ` Vincent Lefevre 2011-04-29 11:15 ` Vincent Lefevre @ 2011-04-29 14:20 ` Bart Schaefer 2011-05-02 8:08 ` Vincent Lefevre 1 sibling, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2011-04-29 14:20 UTC (permalink / raw) To: zsh-workers On Apr 29, 10:44am, Vincent Lefevre wrote: } } > 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 Not really, because if the naive copy is done then the only thing that matters is that len >= 0. } (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. Yes, I was aware of all this, I just didn't think it was worth spelling out (it's implicitly not "naive"). Keep in mind that this portion of zle_tricky.c was written at least 10 years ago by a college student; zsh was rarely if ever built with highly-optimized compilers/libc on 64-bit platforms, at the time. Which is why I said: } > It would not surprise me to } > find this assumption made elsewhere in the zsh sources. I don't suppose you could run through the entire "make check" test suite under valgrind? Even that won't exercise everything but it'll find the ones most likely to bite somebody. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-04-29 14:20 ` Bart Schaefer @ 2011-05-02 8:08 ` Vincent Lefevre 2011-05-02 8:34 ` Vincent Lefevre 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-05-02 8:08 UTC (permalink / raw) To: zsh-workers On 2011-04-29 07:20:32 -0700, Bart Schaefer wrote: > On Apr 29, 10:44am, Vincent Lefevre wrote: > } > 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 > > Not really, because if the naive copy is done then the only thing > that matters is that len >= 0. Well, you can have a naive strcpy() implementation in the C library, but still the compiler is allowed to do any optimization, such as guessing the value of len (or some bounds) from the strcpy() call; this would not affect the behavior at strcpy(), but may affect the use of the len variable in some parts of the code. > } (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. > > Yes, I was aware of all this, I just didn't think it was worth spelling > out (it's implicitly not "naive"). Keep in mind that this portion of > zle_tricky.c was written at least 10 years ago by a college student; > zsh was rarely if ever built with highly-optimized compilers/libc on > 64-bit platforms, at the time. > > Which is why I said: > > } > It would not surprise me to > } > find this assumption made elsewhere in the zsh sources. > > I don't suppose you could run through the entire "make check" test > suite under valgrind? Even that won't exercise everything but it'll > find the ones most likely to bite somebody. That would be a good idea. There's at least one: ==2490== Invalid read of size 1 ==2490== at 0x430AFE: execcmd (exec.c:3011) ==2490== by 0x42CAAC: execpline2 (exec.c:1640) ==2490== by 0x42BC2C: execpline (exec.c:1424) ==2490== by 0x42B2EA: execlist (exec.c:1207) ==2490== by 0x431723: execcmd (exec.c:3259) ==2490== by 0x42CAAC: execpline2 (exec.c:1640) ==2490== by 0x42BC2C: execpline (exec.c:1424) ==2490== by 0x42B2EA: execlist (exec.c:1207) ==2490== by 0x42AD64: execode (exec.c:1028) ==2490== by 0x4235A5: eval (builtin.c:4908) ==2490== by 0x423996: bin_eval (builtin.c:5017) ==2490== by 0x410936: execbuiltin (builtin.c:450) ==2490== Address 0xc22e213 is not stack'd, malloc'd or (recently) free'd It occurs in A04redirect.ztst. -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-05-02 8:08 ` Vincent Lefevre @ 2011-05-02 8:34 ` Vincent Lefevre 2011-05-02 11:54 ` Peter Stephenson 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2011-05-02 8:34 UTC (permalink / raw) To: zsh-workers On 2011-05-02 10:08:39 +0200, Vincent Lefevre wrote: > On 2011-04-29 07:20:32 -0700, Bart Schaefer wrote: > > I don't suppose you could run through the entire "make check" test > > suite under valgrind? FYI, this can be done with: valgrind --trace-children=yes make check > > Even that won't exercise everything but it'll > > find the ones most likely to bite somebody. > > That would be a good idea. There's at least one: > > ==2490== Invalid read of size 1 > ==2490== at 0x430AFE: execcmd (exec.c:3011) > ==2490== by 0x42CAAC: execpline2 (exec.c:1640) > ==2490== by 0x42BC2C: execpline (exec.c:1424) > ==2490== by 0x42B2EA: execlist (exec.c:1207) > ==2490== by 0x431723: execcmd (exec.c:3259) > ==2490== by 0x42CAAC: execpline2 (exec.c:1640) > ==2490== by 0x42BC2C: execpline (exec.c:1424) > ==2490== by 0x42B2EA: execlist (exec.c:1207) > ==2490== by 0x42AD64: execode (exec.c:1028) > ==2490== by 0x4235A5: eval (builtin.c:4908) > ==2490== by 0x423996: bin_eval (builtin.c:5017) > ==2490== by 0x410936: execbuiltin (builtin.c:450) > ==2490== Address 0xc22e213 is not stack'd, malloc'd or (recently) free'd > > It occurs in A04redirect.ztst. This is the only error. It can simply be reproduced by: myfd=99 (echo >&$myfd) 2>msg after zsh -f. -- 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: completion on brace + 4 characters doesn't work 2011-05-02 8:34 ` Vincent Lefevre @ 2011-05-02 11:54 ` Peter Stephenson 0 siblings, 0 replies; 14+ messages in thread From: Peter Stephenson @ 2011-05-02 11:54 UTC (permalink / raw) To: zsh-workers On Mon, 2 May 2011 10:34:43 +0200 Vincent Lefevre <vincent@vinc17.net> wrote: > This is the only error. It can simply be reproduced by: > > myfd=99 > (echo >&$myfd) 2>msg > > after zsh -f. Thanks, this fixes that problem. Index: Src/exec.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/exec.c,v retrieving revision 1.192 diff -p -u -r1.192 exec.c --- Src/exec.c 6 Mar 2011 21:37:38 -0000 1.192 +++ Src/exec.c 2 May 2011 11:53:33 -0000 @@ -3008,10 +3008,11 @@ execcmd(Estate state, int input, int out if (!checkclobberparam(fn)) fil = -1; else if (fn->fd2 > 9 && - ((fdtable[fn->fd2] != FDT_UNUSED && - fdtable[fn->fd2] != FDT_EXTERNAL) || - fn->fd2 == coprocin || - fn->fd2 == coprocout)) { + (fn->fd2 > max_zsh_fd || + (fdtable[fn->fd2] != FDT_UNUSED && + fdtable[fn->fd2] != FDT_EXTERNAL) || + fn->fd2 == coprocin || + fn->fd2 == coprocout)) { fil = -1; errno = EBADF; } else { -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-05-04 9:33 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-04-28 11:11 completion on brace + 4 characters doesn't work Vincent Lefevre 2011-04-28 15:12 ` Bart Schaefer 2011-04-28 22:27 ` Vincent Lefevre 2011-04-29 0:31 ` Vincent Lefevre 2011-04-29 0:59 ` Vincent Lefevre 2011-04-29 1:34 ` Vincent Lefevre 2011-04-29 3:56 ` Bart Schaefer 2011-04-29 8:44 ` Vincent Lefevre 2011-04-29 11:15 ` Vincent Lefevre 2011-05-04 9:33 ` Vincent Lefevre 2011-04-29 14:20 ` Bart Schaefer 2011-05-02 8:08 ` Vincent Lefevre 2011-05-02 8:34 ` Vincent Lefevre 2011-05-02 11:54 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).