Re: [groff] 01/01: preconv: Support Emacs coding tags at file ends.

[G. Branden Robinson]

Two NAKs is enough for me, for this feature.  I'll back out most of it.

I'll probably retain the deletion of the material that indicates it as a
feature that should be implemented since, apparently, it's not.

At 2020-05-08T07:47:11+0100, Ralph Corderoy wrote:
> > This is a more serious bug, a potential security vulnerability:
> > Use after free.
> 
> And I can see a probable wandering off the end of the buffer too.

Yup, my bad.  After Ingo's mail I came up with a new test that exposed
another problem (I only had 11; I needed a twelfth, at least...).

> A non-Unix text editor which liked to do things its way, e.g. the
> three-byte ‘foo’ is a text file.  Putting how to read a file at the
> end of that file is such a daft idea when placed in a Unix context;
> it's alien and should not be encouraged.

Not to rain on the Emacs hate fest, but I'll note two things amidst all
this righteous fury:

1. Vim users put modelines at the end as well (though they can be at the
beginning, and unlike, Emacs's local variables, identical syntax is used
in both places).  There are many reasons people shove this stuff to the
end of the file, and many of them have to do with getting out of the way
of programs that want to parse small amounts of their inputs.

And while we're singing the praises of pipes and the Unix way...

2. Even ed(1) seeks its input when told to.

But that, too, could be regarded as too aggressively DWIMish to
aficionados of early versions of DEC's EDT, where even the buffer
loading was under complete manual control.  You had to specify exactly
which bytes you wanted in you're editor's "view".  There was of course a
limit to that buffer's size, and it was small.

It's probably better just to update the preconv man page (which I was
doing an editing pass on anyway) to explain why the program does not
take what I call "late" local variable regions into account.

Regards,
Branden

signature.asc
Description: PGP signature