Update of bug #55695 (project groff):
Status: Need Info => Invalid
Assigned to: None => gbranden
Open/Closed: Open => Closed
Summary: [PATCH] Troff outputs garbled file names on
MS-Windows => troff outputs garbled file names on MS Windows
_______________________________________________________
Follow-up Comment #4:
Thanks to the anonymous clarifier for the the clarification.
Most programs and (internal, static) libraries in group open files via
standard C library I/O streams (in other words, with fopen()).
There are a few exceptions I'll survey here.
1. groff's Perl programs use Perl's open(); I don't know what Perl does under
the hood.
2. In a few places, the open() system call is employed. With one exception
that I see, this practice corresponds with opening files in "binary mode".
Much of groff's code base is 30+ years old. Perhaps back then, the letter "b"
in fopen()'s mode string was not as portable as one would have hoped (ANSI C
being only a few years old at that point).
3. In one place (xtotroff.c), open() is used (followed by fdopen()) to create
a destination file corresponding to a command-line operand, to avoid racing
with other file system operations (or, rather, to fail if a race occurs). ISO
C11 added the letter "x" as a valid character in fopen()'s mode string to
support this usage. It is possible that this is not yet as portable as we
would hope today. In 2019, Nick Stoughton of the Austin Group (the POSIX
standardization committee) raised an issue with WG14 (the ISO C
standardization committee) regarding the semantics of fopen(..., "[rw]x").
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2357.htm
I haven't chased down if/how that issue got resolved; it doesn't matter for my
purposes because I figure groff code cannot expect reliable semantics from the
"x" mode flag on the environments to which we want to be portable for some
years yet.
However, I observe that:
A. We might want to start migrating to fopen(..., "[rw]b") in the cases of
item 2 above; and
B. We already use gnulib. Maybe gnulib has modules that would help us out
here, and we could stop dropping all the way to system calls for opening files
entirely.
Either of these would be a good item for a groff contributor to take up.
The bottom line is that file specifications supplied to any groff program in
any way (as command line operands or appearing in input streams, for instance
as arguments to `so` or `mso` requests) should use forward slashes as the
directory separator.
Despite being written in C++, groff largely does not use the standard C++
library, notably including its iostream facility, which was in place before
most of the rest of it (including the notorious template library). I have no
ambition to change this.
Resolving as invalid.
Dropping patch annotation from invalid ticket.
Also, as noted in bug #55299, Achim Gratz is maintaining groff for Cygwin now,
not Brian Inglis. Thanks for the correction.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55695>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
