Hello all, During a make of the latest master I got the following warning: gcc -c -I. -I../../Src -I../../Src -I../../Src/Zle -I. -DHAVE_CONFIG_H -DMODULE -Wall -Wmissing-prototypes -O2 -fPIC -o compctl..o compctl.c compctl.c: In function ‘makecomplistflags.isra.6’: compctl.c:3340:7: warning: ‘strcpy’ accessing 1 byte at offsets [0, 9223372036854775807] and [0,9223372036854775807] may overlap 1 byte at offset 0 [-Wrestrict] strcpy(p, p + bl); ^~~~~~~~~~~~~~~~~ rm -f compctl.so Cheers, Wesley -- Wesley Schwengle, Developer Mintlab B.V., https://www.zaaksysteem.nl E: wesley@mintlab.nl T: +31 20 737 00 05
On Wed, 2019-04-03 at 20:59 +0200, Wesley Schwengle wrote: > During a make of the latest master I got the following warning: > > gcc -c -I. -I../../Src -I../../Src -I../../Src/Zle -I. -DHAVE_CONFIG_H > -DMODULE -Wall -Wmissing-prototypes -O2 -fPIC -o compctl..o compctl.c > compctl.c: In function ‘makecomplistflags.isra.6’: > compctl.c:3340:7: warning: ‘strcpy’ accessing 1 byte at offsets [0, > 9223372036854775807] and [0,9223372036854775807] may overlap 1 byte at > offset 0 [-Wrestrict] > strcpy(p, p + bl); > ^~~~~~~~~~~~~~~~~ > rm -f compctl.so This warning is thoroughly opaque --- and not occurring with a locally compiled gcc 8.3.0 on my Ubuntu 16.04 64-bit Intel system --- but the code isn't exactly crystal clear, either (subtracting a number off then adding it immediately back on again isn't generally regarded as great style), and it's quite possible the copy is overlapping. Also, the last person to worry about code optimisation in compctl emigrated to the Undying Lands a decade ago (maybe I can still find the postcard...) Can somebody verify the following is equivalent apart from dealing with a possible overlapping copy? I've no way of ensuring this code gets exercised. Separately, I seem to be having severe problems with --enable-zsh-mem with that configuration. It looked like some failed optimisation involving realloc(). I think we had something similar a while ago? Cheers pws diff --git a/Src/Zle/compctl.c b/Src/Zle/compctl.c index fe87409..f963d57 100644 --- a/Src/Zle/compctl.c +++ b/Src/Zle/compctl.c @@ -3331,13 +3331,11 @@ makecomplistflags(Compctl cc, char *s, int incmd, int compadd) zlemetaline[end] = save; if (brend) { Brinfo bp; - char *p; - int bl; for (bp = brend; bp; bp = bp->next) { - p = lpsuf + (we - zlemetacs) - bp->qpos - - (bl = strlen(bp->str)); - strcpy(p, p + bl); + char *p2 = lpsuf + (we - zlemetacs) - bp->qpos; + char *p1 = p2 - strlen(bp->str); + memmove(p1, p2, strlen(p2) + 1); } } if (!(lpsuf = strchr(lpsuf, '/')) && sf2)
On Thu, 2019-04-04 at 11:21 +0100, Peter Stephenson wrote:
> On Wed, 2019-04-03 at 20:59 +0200, Wesley Schwengle wrote:
> >
> > During a make of the latest master I got the following warning:
> >
> > gcc -c -I. -I../../Src -I../../Src -I../../Src/Zle -I. -DHAVE_CONFIG_H
> > -DMODULE -Wall -Wmissing-prototypes -O2 -fPIC -o compctl..o compctl.c
> > compctl.c: In function ‘makecomplistflags.isra.6’:
> > compctl.c:3340:7: warning: ‘strcpy’ accessing 1 byte at offsets [0,
> > 9223372036854775807] and [0,9223372036854775807] may overlap 1 byte at
> > offset 0 [-Wrestrict]
> > strcpy(p, p + bl);
> > ^~~~~~~~~~~~~~~~~
> > rm -f compctl.so
> This warning is thoroughly opaque --- and not occurring with a locally
> compiled gcc 8.3.0 on my Ubuntu 16.04 64-bit Intel system --- but the
> code isn't exactly crystal clear, either (subtracting a number off then
> adding it immediately back on again isn't generally regarded as great
> style), and it's quite possible the copy is overlapping. Also, the last
> person to worry about code optimisation in compctl emigrated to the
> Undying Lands a decade ago (maybe I can still find the postcard...)
>
> Can somebody verify the following is equivalent apart from dealing with
> a possible overlapping copy? I've no way of ensuring this code gets
> exercised.
I've applied this anyway.
pws
[-- Attachment #1: Type: text/plain, Size: 487 bytes --] On Wed, Apr 10, 2019 at 10:48 AM Peter Stephenson <p.stephenson@samsung.com> wrote: > On Thu, 2019-04-04 at 11:21 +0100, Peter Stephenson wrote: > > > Can somebody verify the following is equivalent apart from dealing with > > a possible overlapping copy? I've no way of ensuring this code gets > > exercised. > > I've applied this anyway. > I'm pretty sure your code is equivalent to the original (apart from being correct if ranges overlap). It's also easier to understand. Roman.