[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: potential inconsistency with buffer modified flag

From: Antonio Diaz Diaz
Subject: Re: potential inconsistency with buffer modified flag
Date: Sat, 11 Nov 2023 17:38:59 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20110420 SeaMonkey/2.0.14

Eric Blake wrote:
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.

IIRC, GNU ed sets the modified flag when it changes the buffer, even if the buffer contents are identical before and ater the change. For example, 's/a/a/' sets the modified flag.

In this sense, appending an empty or non-existent file does not change the buffer, and therefore does not set the modified flag. This is much like any other "empty" command that does not change the buffer, in which case the modified flag is not set:

$ ed -v ; echo $?

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').

Maybe all the commands that can't change the buffer contents, namely f, h, H, k, l, n, p, P, #, =, and the null command, could be allowed in between a notification that a buffer was modified and a followup attempt to quit. I'm willing to implement such a change.

You can see where we left off today;
https://posix.rhansen.org/p/2023-11-09 (start around line 275 in that

I get:
"You do not have permission to access this pad"
"Sorry, you have to enable Javascript in order to use this."

Is there a text/plain or text/html version of that etherpad that can be read without creating yet another account and without executing javascript?

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.

I don't think that any of the changes being proposed is too onerous. In fact I plan to implement even the resolution of bug 251 (and more) and make GNU ed reject characters 0 to 31 in file names unless they are allowed with a command-line option. (Perhaps '--unsafe-names').

BTW, re bug 1786, I don't follow the logic of implementations like FreeBSD 13 to not allow the creation of a file in the obvious way of supplying the file name in the command line. I find it convenient that GNU ed allows it:

$ ed -v zutils.conf
zutils.conf: No such file or directory
gz = pigz -p2
lz = plzip -n2
$ cat zutils.conf
gz = pigz -p2
lz = plzip -n2

Maybe POSIX should recommend for the 'e' command with a non-existing file that "a warning is emitted in place of a byte count and the resulting buffer is left empty".

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]