Re: potential inconsistency with buffer modified flag

[Eric Blake]

On Fri, Nov 10, 2023 at 12:08:12AM +0100, Antonio Diaz Diaz wrote:
> Eric Blake wrote:
> > During today's Austin Group meeting (the folks working on POSIX), we
> > noticed an inconsistency in GNU ed when compared to other
> > implementations.  It seems that ALL implementations we tested allow
> > 'q' to quit immediately after an 'e' that failed because the buffer
> > still has unwritten modifications:
> > [...]
> > We then tried to figure out what other commands, if any, can be used
> > in between notification that a buffer was modified and a followup
> > attempt to quit.  On MacOS, 'h' does not count as an intervening
> > command:
> 
> Thank you very much for reporting this. I'll implement both behaviors in GNU
> ed as soon as possible (in a few days).

Some other things we noted today: GNU ed treats 'r /dev/null' (or any
other 0-byte file) as a command that does not modify the buffer
changed status.  Conversely, ed on MacOS treats the buffer as modified
even when zero bytes are read.  On that front, the POSIX folks were
okay with both behaviors, and wanted to change the wording to permit
both.  But it got more questionable with other commands: POSIX is
already clear that 's/a/a/' can update the current line (even though
it doesn't update contents), so it seems reasonable to have it always
mark the buffer as modified.  And even if you use 'c' to replace a
line with the same contents, the act of deletion and re-addition seems
like a reason to set the flag.  It's harder to argue whether '='
modifies the buffer, and even harder for things like 'H' or 'P'; but
we were leaning towards any command that prevents the sequence
'e',$cmd,'q' from exiting as being required to set the buffer modified
flag even if it did not change the buffer contents (which was how we
noticed the inconsistency between GNU and MacOS when $cmd is 'h').

You can see where we left off today;
https://posix.rhansen.org/p/2023-11-09 (start around line 275 in that
document).  The notes in that etherpad are still in rough shape
because we are still considering if other wording tweaks are needed
(we already know we need to fix the sentence in draft 3 line 92845
about "If the e or q command is repeated with no intervening command,
it shall take effect." to cover the fact that 'q' immediately after a
failed 'e' did quit in all tested implementations).  When our text
tweaks are finally ready (possibly next Monday), we'll add it to
https://austingroupbugs.net/view.php?id=1786 and start a 30-day
review, but since you'll possibly be impacted by the change (whether
to change GNU ed to match, or to offer a counterpoint why the Austin
Group proposed changes are too onerous and failed to take into
consideration existing practice), feel free to chime in now rather
than waiting.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org