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