Binary Mode stdin/stdout
Markus Kuhn
the standard input and output into binary transparent mode (as with
the "b" flag in fopen()/freopen() for normal files)?
Has this just been forgotten or is there a good technical reason?
The lack of a function which makes stdin/stdou binary transparent is
always a pain if you port software (e.g. zcat) which can under Unix be
used to pipe binary files from one program to the next to systems like
MS-DOS where there is a difference between binary and text mode
streams.
Markus
--
Markus Kuhn, Computer Science student -- University of Erlangen,
Internet Mail: <msk...@cip.informatik.uni-erlangen.de> - Germany
WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>
Clive D.W. Feather
Markus Kuhn <msk...@cip.informatik.uni-erlangen.de> wrote:
> Why isn't there a standard way of allowing an ISO C program to switch
> the standard input and output into binary transparent mode (as with
> the "b" flag in fopen()/freopen() for normal files)?
>
> Has this just been forgotten or is there a good technical reason?
On some implementations, this decision has to be made at the time you
open the file and can't be changed. For example, on OS/360 and its
successors, text files might be VB80, while binary files will be U508,
or whatever. The former is stored as:
<4 byte value N1> <N1 bytes of text forming a line>
<4 byte value N2> <N1 bytes of text forming a line>
<4 byte value N3> <N1 bytes of text forming a line>
...
(note that there are no newline characters) and the latter as
<4 byte value N1> <N1 bytes of data> <508-N1 bytes ignored>
<4 byte value N2> <N1 bytes of data> <508-N1 bytes ignored>
<4 byte value N3> <N1 bytes of data> <508-N1 bytes ignored>
...
(data is read and written in 512 byte units). How do you switch these ?
--
Clive D.W. Feather | If you lie to the compiler,
cd...@cityscape.co.uk (work, preferred) | it will get its revenge.
cl...@stdc.demon.co.uk (home) | - Henry Spencer
Markus Kuhn
>In article <4f67kg$1...@cortex.dialin.rrze.uni-erlangen.de>,
>Markus Kuhn <msk...@cip.informatik.uni-erlangen.de> wrote:
>> Why isn't there a standard way of allowing an ISO C program to switch
>> the standard input and output into binary transparent mode (as with
>> the "b" flag in fopen()/freopen() for normal files)?
>>
>> Has this just been forgotten or is there a good technical reason?
>On some implementations, this decision has to be made at the time you
>open the file and can't be changed.
I would already be happy with a portable function that allows to
switch stdin or stdout to binary mode and that has only a well-defined
behaviour according to the standard if this switch occurs before any
byte has been written to or read from the stream. This would cause no
headaches on your computing fossil (because inserting a newline during
a later switch would not be non-conforming) and would be sufficient
for all important applications I can think of (like zcat).
Nick Maclaren
|> cl...@stdc.demon.co.uk (Clive D.W. Feather) writes:
|>
|> >In article <4f67kg$1...@cortex.dialin.rrze.uni-erlangen.de>,
|> >Markus Kuhn <msk...@cip.informatik.uni-erlangen.de> wrote:
|> >> Why isn't there a standard way of allowing an ISO C program to switch
|> >> the standard input and output into binary transparent mode (as with
|> >> the "b" flag in fopen()/freopen() for normal files)?
|> >>
|> >> Has this just been forgotten or is there a good technical reason?
|>
|> >On some implementations, this decision has to be made at the time you
|> >open the file and can't be changed.
|>
|> I would already be happy with a portable function that allows to
|> switch stdin or stdout to binary mode and that has only a well-defined
|> behaviour according to the standard if this switch occurs before any
|> byte has been written to or read from the stream. This would cause no
|> headaches on your computing fossil (because inserting a newline during
|> a later switch would not be non-conforming) and would be sufficient
|> for all important applications I can think of (like zcat).
In article <4fbnr3$v...@usenet.pa.dec.com>, dia...@tko.dec.com (Norman Diamond) writes:
|>
|> I'll take your word for it. I suppose the operating system would require
|> the program to close the file and reopen it, so that is what the C standard
|> requires the C program to do. (This is also why the C standard requires C
|> programs to simulate long int arithmetic on their own instead of building
|> it into the language, since some hardware doesn't have it, right?)
Sorry, but these wouldn't work even on UNIX. Not all 'files' can
be closed and reopened - think of rewinding tapes, for example!
Even on MVS, it would be possible to have a run-time flag that
selected between binary and text for stdin and stdout, but this
would have nothing to do with the C standard. When I wrote my
interface, I never provided this because I regarded it as being
more confusion than it was worth - remember that C binary I/O
does not map well onto MVS sequential files.
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Thomas Koenig
>You make an assumption that the operating system provides you with a means
>of directing binary data into stdin or recieving it from stdout in the first
>place.
The same kind of assumption is being made with system(). A function
to switch stdin or stdout to binary could return failure if necessary.
--
Thomas Koenig, Thomas...@ciw.uni-karlsruhe.de, ig...@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
Stephen Baynes
: cl...@stdc.demon.co.uk (Clive D.W. Feather) writes:
: >In article <4f67kg$1...@cortex.dialin.rrze.uni-erlangen.de>,
: >Markus Kuhn <msk...@cip.informatik.uni-erlangen.de> wrote:
: >> Why isn't there a standard way of allowing an ISO C program to switch
: >> the standard input and output into binary transparent mode (as with
: >> the "b" flag in fopen()/freopen() for normal files)?
: >>
: >> Has this just been forgotten or is there a good technical reason?
: >On some implementations, this decision has to be made at the time you
: >open the file and can't be changed.
: I would already be happy with a portable function that allows to
: switch stdin or stdout to binary mode and that has only a well-defined
: behaviour according to the standard if this switch occurs before any
: byte has been written to or read from the stream. This would cause no
: headaches on your computing fossil (because inserting a newline during
: a later switch would not be non-conforming) and would be sufficient
: for all important applications I can think of (like zcat).
You make an assumption that the operating system provides you with a means
of directing binary data into stdin or recieving it from stdout in the first
place. There is nothing to stop an operating system from insisting that
stdin and stdout are conly onnected to a text terminal. If you are writing
truely portable code then you would be better to not expect too much from
the OS.
[On the other hand I agree it would be useful to switch the mode though one
would have to accept it might fail or be useless - but almost anything to do
with stdin and stdout can fail or be useless so that is not a bit deal.
However there are plenty of other things to do with files that would be useful
such as switching from readonly to readwrite and truncating an already open
file.]
--
Stephen Baynes bay...@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton My views are my own.
United Kingdom
Lawrence Kirby
nm...@cus.cam.ac.uk "Nick Maclaren" writes:
>Sorry, but these wouldn't work even on UNIX. Not all 'files' can
>be closed and reopened - think of rewinding tapes, for example!
But of course to change file mode between text and binary on Unix doesn't
require the file to be closed and reopened. In fact it requires
remarkably little effort! :-)
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------