Applied, thank you
On Thu, Dec 22, 2022 at 3:30 PM Sören Tempel wrote:
>
> PING.
>
> Any love for good old ed(1)?
>
> Sören Tempel wrote:
> > Pinging again as this is still unfixed and the proposed fix is rather
> > trivial.
> >
> > Sören Tempel wrote:
> > > Ping.
> > >
> > >
From: Sören Tempel
> Sent: 22 December 2022 14:23
>
> PING.
>
> Any love for good old ed(1)?
Some versions of glibc will also do 'not strictly increasing'
memcpy() on some x86 cpu.
Just copying the last 4/8 bytes first and then doing a forwards
copy is enough to break things.
David
>
PING.
Any love for good old ed(1)?
Sören Tempel wrote:
> Pinging again as this is still unfixed and the proposed fix is rather trivial.
>
> Sören Tempel wrote:
> > Ping.
> >
> > soe...@soeren-tempel.net wrote:
> > > From: Sören Tempel
> > >
> > > The memcpy invocations in the subCommand
Pinging again as this is still unfixed and the proposed fix is rather trivial.
Sören Tempel wrote:
> Ping.
>
> soe...@soeren-tempel.net wrote:
> > From: Sören Tempel
> >
> > The memcpy invocations in the subCommand function, modified by this
> > commit, previously used memcpy with overlapping
Ping.
soe...@soeren-tempel.net wrote:
> From: Sören Tempel
>
> The memcpy invocations in the subCommand function, modified by this
> commit, previously used memcpy with overlapping memory regions. This is
> undefined behavior. On Alpine Linux, it causes BusyBox ed to crash since
> we compile
From: Sören Tempel
The memcpy invocations in the subCommand function, modified by this
commit, previously used memcpy with overlapping memory regions. This is
undefined behavior. On Alpine Linux, it causes BusyBox ed to crash since
we compile BusyBox with -D_FORTIFY_SOURCE=2 and our
