Mail Archives: djgpp/2021/03/27/10:02:14
> From: "Ozkan Sezer (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
> Date: Sat, 27 Mar 2021 16:39:08 +0300
>
> The code is basically:
>
> p = popen(cmdline, "rb");
> while ((n = fread(buf, 1, BUFLEN, p)) > 0) {
> fwrite(buf, 1, n, t);
> }
> pclose(p);
>
> ... where cmdline is like "unrar p -inul ponylips.rar". The "p" makes
> unrar to extract to stdout, -inul makes unrar to emit no messages.
>
> The issue is: Whatever I do, including inserting calls like
> setmode(fileno(stdout),O_BINARY), extracted file has 0x0a -> 0x0d 0x0a
> changes and corrupted. For what it's worth, manually running that cmd
> on the console itself, like "unrar p -inul ponylips.rar > ponylips.mod"
> gives the same result.
I don't think I understand what you mean by "extracted file has 0x0a
-> 0x0d 0x0a changes and corrupted".
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
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.
- Raw text -