Re: [Groff] gpreconv on Windows fails with CRLF files

[Keith Marshall]

On 05/08/12 18:57, Anton Shepelev wrote:
> I wrote:
> 
>> Is it reasonable to modify gpreconv or its Windows
>> port so that on Windows it will expect '\r\n'?

As a software developer, writing code primarily for Windows, I feel
obliged to chime in with an emphatic "no" here.

> preconv(1) says:
> 
>     Trailing '-dos', '-unix', and '-mac' suffixes of
>     coding  tags (which give the end-of-line conven-
>     tion used in the file) are stripped  off  before
>     the comparison with the above tags happens.
> 
> Why not pay heed to these suffixes instead of strip-
> ping them and always assuming  '-unix',  and  assume
> '-dos' on Windows?

Why would you want it to do that?  Why should preconv be expected to
care whether its input data stream originated on *nix, mac or dos?

preconv is written in C++, right?  It processes an input stream which
may be nominally classified as "text"; i.e. a stream of variable length
records, comprising nominally printable character codes, (according to
some specific encoding standard), and each terminated by a specific end
of line indicator.  Microsoft's own C/C++ API, for processing such data
streams, converts \r\n to \n by default, before the application code,
(preconv, in this case), ever sees it; thus, the behaviour described in
the preconv(1) snippet above is completely consistent with the default
behaviour [*] of Windows own text processing convention, as it is
implemented for applications written in C or C++.

[*] Actually, preconv opens its input stream in "binary" mode, rather
than in Window's special "text" mode.  Thus, it does see the \r\n EOL
sequence, which it then explicitly interprets as the line terminator, so
explicitly emulating the behaviour which would have been default, had it
been opened in "text" mode.  Why it does this, I don't know; perhaps the
original implementer will chime in with an explanation.

-- 
Regards,
Keith