Re: potential inconsistency with buffer modified flag

[Antonio Diaz Diaz]

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 $?
a
.
q
0

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

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
a
gz = pigz -p2
lz = plzip -n2
.
wq
29
$ 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,
Antonio.