Paul and Douglas, The proposed solution of deferring the diagnostic to the actual file I/O raises three key issues. First, red (restricted ed) will still give its own diagnostic for the example argument:
FILE/: Directory access restricted This diagnostic cannot be removed, as red is designed not to have access to other directories. Secondly, the function being modified is invoked by several ed commands, including the "f" command, which does no immediate I/O and thus will not trigger any warning of its own at all with the patched code and given example: *f FILE/ FILE/ Thirdly, once a file is written with the example filename, errno is still set in such a way as to display basically the same diagnostic as before: *w FILE/: Is a directory ? *h Cannot open output file Therefore, I see leaving such paths unvalidated as an inadequate solution. As an aside, when I compiled the executable with the patch, it was exactly the same size as the build of the currently released version. I concede that a build with proper validation code would likely be slightly larger. Alexander On Sun, Jan 11, 2026 at 10:49 AM Douglas McIlroy <[email protected]> wrote: > > Paul, > > I'm impressed by the quick action. I was too lazy to look up the source, but > the cause and fix were exactly as I had imagined. > > Thanks, > Doug > > On Sun, Jan 11, 2026 at 11:07 AM Paul Eggert <[email protected]> wrote: >> >> On 2026-01-11 01:21, Alexander Jones wrote: >> > Whether Antonio wants to expend the coding effort to do a stat call to >> > check whether the filename is an actual directory just for proper >> > diagnostic output is up to him. >> >> There is no need for a stat call. Just open the file and read it as >> usual. If that fails, diagnose the problem as usual. >> >> The coding effort here is simple: remove the code that checks whether >> the file name is empty or ends in "/". This simplifies things (and makes >> "ed" a tiny bit smaller and faster - isn't that the point of "ed"? :-). >> >> Proposed patch attached. >> >> (cc'ing Doug McIlroy who originally reported the bug to a different >> mailing list.)
