[Groff] Re: grohtml 1.19.2/Win32--troff 'o' Option

[MARSHALL Keith]

> I would like to encapsulate Keith's code into a macro, say,
> FLUSH_PIPE(), which is defined in nonposix.h.

This certainly would help to keep the peculiarities of the Win32
implementation localised in nonposix.h, thus leading to cleaner
code elsewhere.

My own personal preference would be for a macro name such as
DRAIN_INPUT_PIPE(), or perhaps FLUSH_INPUT_PIPE(). In my mind, I
tend to associate the flush operation with ensuring that write
buffers are copied out to the file system -- an operation which
is not normally required on input streams -- and I like my macro
names to be as explicit as possible, about their intent.  This is
a minor issue, however, and I will happily conform to whatever
Werner prefers.

Here is a possible implementation, for inclusion in nonposix.h:

   #if defined(_WIN32) && !defined(__CYGWIN__)
   #   define DRAIN_INPUT_PIPE( FD )        \
       do if( ! isatty( FD ) )              \
       {                                    \
         int drain;                         \
         while( read( FD, &drain, 1 ) > 0 ) \
           ;                                \
       } while( 0 )
   #else
   #   define DRAIN_INPUT_PIPE( FD )
   #endif

which would allow us to simply use

   DRAIN_INPUT_PIPE( STDIN_FILENO );

unconditionally, in the cleanup_and_exit() implementation.

Note that I have restricted the macro code to the Win32 case,
and have provided a 'do nothing' dummy for other cases; we
require this code only for the Win32 case, but the compiler
does need a default definition for other cases, (and there may
be other Win32 cases, in addition to Cygwin, for which it is
not required).

Also note the use of the do ... while construct, as described at
gcc.gnu.org/onlinedocs/gcc-3.3.2/cpp/Swallowing-the-Semicolon.html

Just a brief word of caution; this coding example does no error
handling!  The manpage for read(2) indicates a number of possible
error returns -- return value == -1, status in 'errno' -- which
we may need to handle; however, a quick check on MSDN suggests
that only EBADF is applicable for the MSVCRT implementation; I
am not sure if we need to handle this one, or if we can simply
treat it as equivalent to EOF, (which this code already does).

Best regards,
Keith.