Binary mode???

[Shraddha]

Why we should use binary mode of file? Where it is going to be
actually needed???

[Walter Roberson]

In article <11**********************@j4g2000prf.googlegroups. com>,
Shraddha <sh*************@gmail.comwrote:

>Why we should use binary mode of file? Where it is going to be
actually needed???

MS Windows. Text files there have their lines delimited by
carriage return + linefeed pairs, the pair together reading in
as a single \n in text mode. If you used text mode to try to
write out a file of binary data, and happened to write out
a linefeed (pretty likely by chance in a file of any significant
size) then instead of having just the linefeed output, both
carriage return and linefeed would be output (on that particular
platform.) That's going to ruin the file in many circumstances.

--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[Richard Heathfield]

Shraddha said:

Why we should use binary mode of file?

If you mean "why should we open a file in binary mode?", the answer is
"because we want to access the file as a raw stream of bytes, rather
than as a newline-delimited text file."

Where it is going to be actually needed???

When you're opening a file that isn't an ordinary text file, or even
when you want to access an ordinary text file as if it weren't one.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Mark McIntyre]

On Thu, 21 Jun 2007 10:30:15 -0700, in comp.lang.c , Shraddha
<sh*************@gmail.comwrote:

>Why we should use binary mode of file? Where it is going to be
actually needed???

If youre storing or reading binary data, use binary mode.

any OSen translate certain characters when tehy're written in text
mode - such as the end-of-line marker, the end-of-file marker etc.
So if you wrote a JPEG image out using text mode, the data would be
garbled. Ditto, in reverse, when you're reading it back in again.

By the way, windows isn't the only OS to do this, and not all OSes do
it the same way - MacOS, MSDOS, VMS (I think) probably CP/M and
probably TOS and AmigaDos all seem to do it, though not in the same
way.

Myself, I think Unix has it wrong - to return to the next line on my
teletype, I definitely need a CR and an LF.....

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Bill Waddington]

On Thu, 21 Jun 2007 18:50:03 +0100, Mark McIntyre
<ma**********@spamcop.netwrote:

>On Thu, 21 Jun 2007 10:30:15 -0700, in comp.lang.c , Shraddha
<sh*************@gmail.comwrote:

>>Why we should use binary mode of file? Where it is going to be
actually needed???

If youre storing or reading binary data, use binary mode.

[snip]

>Myself, I think Unix has it wrong - to return to the next line on my
teletype, I definitely need a CR and an LF.....

And definitely in that order...

Bill (nostalgic, but way OT)
--
William D Waddington
wi****************@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

[Lew Pitcher]

On Jun 21, 2:22 pm, Bill Waddington <[e-mail]>
wrote:

On Thu, 21 Jun 2007 18:50:03 +0100, Mark McIntyre

<[e-mail]:

On Thu, 21 Jun 2007 10:30:15 -0700, in comp.lang.c , Shraddha
<[e-mail]:

>Why we should use binary mode of file? Where it is going to be
actually needed???

If youre storing or reading binary data, use binary mode.

[snip]

Myself, I think Unix has it wrong - to return to the next line on my
teletype, I definitely need a CR and an LF.....

And definitely in that order...

Possibly padded with up to three trailling ASCII NUL (0x00) bytes

[Eric Sosman]

Mark McIntyre wrote On 06/21/07 13:50,:

On Thu, 21 Jun 2007 10:30:15 -0700, in comp.lang.c , Shraddha
<sh*************@gmail.comwrote:

>>Why we should use binary mode of file? Where it is going to be
actually needed???

If youre storing or reading binary data, use binary mode.

any OSen translate certain characters when tehy're written in text
mode - such as the end-of-line marker, the end-of-file marker etc.
So if you wrote a JPEG image out using text mode, the data would be
garbled. Ditto, in reverse, when you're reading it back in again.

By the way, windows isn't the only OS to do this, and not all OSes do
it the same way - MacOS, MSDOS, VMS (I think) probably CP/M and
probably TOS and AmigaDos all seem to do it, though not in the same
way.

Myself, I think Unix has it wrong - to return to the next line on my
teletype, I definitely need a CR and an LF.....

<topicality level=marginal>

So, you're saying the end-of-line convention for Unix
should be CR LF NUL NUL NUL? Or maybe a varying number of
NULs depending on the length of the line and the speed of
the modem?

</topicality>

--
Er*********@sun.com

[Lew Pitcher]

On Jun 21, 3:15 pm, Eric Sosman <[e-mail]:

Mark McIntyre wrote On 06/21/07 13:50,:

On Thu, 21 Jun 2007 10:30:15 -0700, in comp.lang.c , Shraddha
<[e-mail]:

>Why we should use binary mode of file? Where it is going to be
actually needed???

If youre storing or reading binary data, use binary mode.

any OSen translate certain characters when tehy're written in text
mode - such as the end-of-line marker, the end-of-file marker etc.
So if you wrote a JPEG image out using text mode, the data would be
garbled. Ditto, in reverse, when you're reading it back in again.

By the way, windows isn't the only OS to do this, and not all OSes do
it the same way - MacOS, MSDOS, VMS (I think) probably CP/M and
probably TOS and AmigaDos all seem to do it, though not in the same
way.

Myself, I think Unix has it wrong - to return to the next line on my
teletype, I definitely need a CR and an LF.....

<topicality level=marginal>

So, you're saying the end-of-line convention for Unix
should be CR LF NUL NUL NUL? Or maybe a varying number of
NULs depending on the length of the line and the speed of
the modem?

Long ago, at the lowest level (output from line conditioning and
serial driver, for instance), it was often necessary to add padding
characters after the CR LF to compensate for very slow mechanical
parts. IIRC, Unix did this sort of thing circa Version 3 or earlier.

Nowadays, it is likely very unnecessary to do such padding

(BTW, I was just responding to Bill's "nostalgia" remark :-) )

</topicality>

--
[e-mail]

[Lew Pitcher]

On Jun 21, 3:20 pm, Lew Pitcher <[e-mail]:

On Jun 21, 3:15 pm, Eric Sosman <[e-mail]:

Mark McIntyre wrote On 06/21/07 13:50,:

On Thu, 21 Jun 2007 10:30:15 -0700, in comp.lang.c , Shraddha
<[e-mail]:

>>Why we should use binary mode of file? Where it is going to be
>>actually needed???

If youre storing or reading binary data, use binary mode.

any OSen translate certain characters when tehy're written in text
mode - such as the end-of-line marker, the end-of-file marker etc.
So if you wrote a JPEG image out using text mode, the data would be
garbled. Ditto, in reverse, when you're reading it back in again.

By the way, windows isn't the only OS to do this, and not all OSes do
it the same way - MacOS, MSDOS, VMS (I think) probably CP/M and
probably TOS and AmigaDos all seem to do it, though not in the same
way.

Myself, I think Unix has it wrong - to return to the next line on my
teletype, I definitely need a CR and an LF.....

<topicality level=marginal>

So, you're saying the end-of-line convention for Unix
should be CR LF NUL NUL NUL? Or maybe a varying number of
NULs depending on the length of the line and the speed of
the modem?

Long ago, at the lowest level (output from line conditioning and
serial driver, for instance), it was often necessary to add padding
characters after the CR LF to compensate for very slow mechanical
parts. IIRC, Unix did this sort of thing circa Version 3 or earlier.

Nowadays, it is likely very unnecessary to do such padding

(BTW, I was just responding to Bill's "nostalgia" remark :-) )

<topicality level="way off topic">

FWIW, Unix character device (terminal) support still provides this,
sort of, with the OFILL termios() option.

</topicality>

</topicality>

--
[e-mail]

[Mark McIntyre]

On Thu, 21 Jun 2007 12:20:44 -0700, in comp.lang.c , Lew Pitcher
<lp******@teksavvy.comwrote:

(Eric wrote)

> So, you're saying the end-of-line convention for Unix
should be CR LF NUL NUL NUL? Or maybe a varying number of
NULs depending on the length of the line and the speed of
the modem?

Long ago, at the lowest level (output from line conditioning and
serial driver, for instance), it was often necessary to add padding
characters after the CR LF to compensate for very slow mechanical
parts. IIRC, Unix did this sort of thing circa Version 3 or earlier.

ISTR the chain drive on the printer in my lab used to jump off if you
sent it a CR/LF and then a printable character immediately, so NULs
were definitely required. Apparently a mechanical constraint about how
fast the chain could pull the drum round etc...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Shraddha <sh*************@gmail.comwrites:

Why we should use binary mode of file? Where it is going to be
actually needed???

The comp.lang.c FAQ is at <http://www.c-faq.com/>. Section 12 covers
stdio; question 12.40 addresses your question.

Please check the FAQ before posting questions here; that's what it's
for.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"