Re: more m4p bugs

Nikolaos Chatzikonstantinou <[email protected]> Tue, 20 May 2025 06:34:31 -0400
Newsgroups gmane.comp.gnu.m4.general
Message-ID <CAAQmekfkd1ORmhiP066fMqwofxfjUkOerRq9cLfVwBc2VB+T3w@mail.gmail.com>
On Mon, May 19, 2025 at 10:02=E2=80=AFPM Eric Blake <[email protected]> wro=
te:
>
> On Mon, May 19, 2025 at 02:36:50PM -0500, Eric Blake wrote:
> > > > > > Now testing with b686ed, you have a problem with redefining a m=
acro as
> > > > > > empty if it has been undefined in the meantime:
> >
> > Another cute stack trace worth fixing:
>
> Messing around, this one has odd behavior interactively (here, using
> =3D> on the lines I typed):
>
> $ m4p
> =3D>hi
> hi
> =3D>changecom(//,-)
> =3D>what happened
> =3D>^D
>
> what happened
>
> It looks like the act of setting changecom() to use a start character
> longer than one byte ends up in getting the output off (the newline is
> not getting echoed soon enough).

This was a tricky "off-by-one" newline error. If there was a buffered
newline in stdin I made the mistake of attempting to read again. The
syscmd bug was also tricky and you were right about what happened.
With eval() I think I was a bit careless.

With 0.7.5 I attempted to fix all the reported bugs.

Regards,
Nikolaos Chatzikonstantinou