Mail Archives: djgpp/2021/03/27/10:26:21
> From: "Ozkan Sezer (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
> Date: Sat, 27 Mar 2021 17:18:20 +0300
>
> > The above program's expected effect is to read what "unrar -p" emits
> > without any EOL conversions. Programs that run on MS-DOS/Windows
> > usually output CRLF end-of-line sequences (i.e. 0x0d + 0x0a), so the
> > program you show should:
> >
> > . read these CRLF EOLs without any conversion
> > . write each line to stdout
>
> OK, so it's possibly an issue with unrar itself
You expected unrar to produce lines with a single 0x0a at the end of
each line? That's extremely unusual with DOS/Windows programs.
> > Whether 'fwrite' add another 0x0d to each line depends on the mode of
> > the stream 't'; if you open it in binary mode, I would expect to see
> > the same CRLF EOLs as what "unrar -p" emits. If 't' is in text mode,
> > you will see each line end with 0x0d 0x0d 0x0a, i.e. 2 CR characters
> > followed by a single newline.
>
> It's opened with "w+b" mode, like:
> fd = mkstemp(*filename);
> t = fdopen(fd, "w+b");
Then you should expect to see the CRLF end of line in the temporary
file, I think.
- Raw text -