[re-titling sub-thread again] At 2025-02-22T17:59:10-0600, Dave Kemper wrote: > I still suspect that that benefit stands even if the file-opening > function is modified to chop trailing spaces from the name. That > would prevent groff from opening a file named "trailing space ", but > any real-world files with such names are probably either typos or > attempts to do something underhanded. Such a change would also create > nonorthogonality between how requests .ds and .nx operate, but I think > creating groff strings with trailing spaces can be useful, while > opening files with them rarely-to-the-point-of-never is. > > Ultimately I considered the back-compatibility breakage to be minor > and easily rectified, so I didn't push for this change.
My lodestar on this point is that we can use C and the shell to create files named with trailing spaces, so there's no reason *roff, as a bona fide programming language, shouldn't be capable as well--as long as it's not difficult to implement. Further, because such file names _are_ so easy to create in C and the shell, I think if there were dangerously underhanded threats in the offing, we'd have seen them by now. It's not like people need to smuggle such things onto the file system under the cover of a *roff document. (In GNU troff, since "safer mode" is on by default, a document can't _create_ a file of _any_ name on its own initiative.) Floating-point arithmetic is an instructive point of contrast, _because_ it's so much heavier a lift. Of course C supports it; some Unix shells do and others don't. (I think Korn Shell was the first, or maybe it didn't come along until CDE's dtsh?) Regards, Branden
signature.asc
Description: PGP signature
