text and binary streams

S

subramanian100in

In K & R ANSI C book(2nd Edition), in page 241, the following lines
are mentioned.

"The library supports text streams and binary streams, although on
some systems, notably UNIX, these are identical."

Here I am unable to understand what is meant by saying "the streams
are identical" ?

Kindly clarify. If possible give an example so that I can understand.

Thanks
V.Subramanian
 
R

Richard Tobin

In K & R ANSI C book(2nd Edition), in page 241, the following lines
are mentioned.

"The library supports text streams and binary streams, although on
some systems, notably UNIX, these are identical."

Here I am unable to understand what is meant by saying "the streams
are identical" ?

The best-known example is the difference in how line-endings are
represented in unix and msdos-derived systems. Unix uses a single
linefeed character at the end of each line. Windows uses the
two-character sequence carriage-return-linefeed.

C specifies that when reading text files you get a linefeed at the end
of each line, so on MS Windows the system has to translate cr-lf to lf
in text mode (and the reverse for writing), but not in binary mode.
On unix the file representation is already the same as C's, so no
translation is needed in text mode, and it works just the same way as
binary mode.

-- Richard
 
J

James Kuyper

In K & R ANSI C book(2nd Edition), in page 241, the following lines
are mentioned.

"The library supports text streams and binary streams, although on
some systems, notably UNIX, these are identical."

Here I am unable to understand what is meant by saying "the streams
are identical" ?

Kindly clarify. If possible give an example so that I can understand.

Binary streams are simply read and written byte by byte. Text streams
are allowed to be processed in a more complicated fashion. To take the
simplest example, on DOS/Windows systems, writing a single '\n'
character causes two bytes to be written to the output file, "\r\n" or
"\n\r", I can't remember which. Other systems have the opposite order.
Some systems store text streams in fixed-sized blocks, keeping each line
of text in a separate block, padding it with null characters or blanks
to the end of the block, or storing a count in each block of how many
bytes of the block are currently in use.

If you open the file for writing in text mode; if you never write
anything to it other than printing characters (see isprint()), '\t', and
'\n'; if you never write a space character prior to a '\n'; if you
always end a file with a '\n' character, then you when you close the
file and reopen it for reading in text mode, you will get back exactly
the same text you wrote. This is all taken care of invisibly. Note: it's
implementation defined whether or not spaces printed out before a '\n'
will appear when you read back the line.

However, in every case where the standard allows for more complicated
handling for text streams, simply reading and writing a single byte at a
time in sequential order is always an option. On some systems (most
notably, on Unix and Unix-like systems), that is precisely what is done.
The result is that it makes no difference whether you open the file in
text mode or binary mode. If you write a '\n' character to a file, a
single byte with a value of '\n' is written to the file.
 
H

Herbert Rosenau

Which only goes to prove that if there were "\n\r" systems in the
early 80's, they weren't used in the sort of places that bought our
products.

I don't think that ever a system using '\n\r' would exist. Because
based on the very old times before even CP/M was existent there were
existent priters (e.g. on TTY) who used '\r' to move the print head to
begin of line only and '\n' only to move the paper try a line up.
Whereas using '\n' followed by '\r' and then the next letter printing
out that letter on the fly where the carridge was underway to begin of
line, whereas the sequence '\r\n' caused the print unit to wait until
the carridge had reached t
he begin of line position before the '\n' was carried out.

A sample:

You had used
fprintf("----------------------------------------------------\n\r");
fprintf("monkey\r/n");
The printout looked like
-
------------------------------------------------------------
ey k on m


instead of
------------------------------------------------------------
monkey

as it should. So it was essential to print out '\r' before '\n' to
give the print unit time to let the carridge return, and then paper
try was holding the unit until it was finished the paper one line
forward, because it had to reead its punched paper stripe that
signaled the step wide a line and a page was high.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
 
P

Peter Nilsson

Eric Sosman said:
Jack said:
[... concerning line-ending conventions ...]

I don't know of any platform that used the "\n\r" order,
but there might well have been some.

     A long-dead (and little-regretted) Raytheon system
bracketed each line with a '\r' at the start and a '\n'
at the end.  Thus, the last character of one line and
the first character of the next were divided by the
sequence "\n\r" -- not truly a single separator (which
wouldn't explain the conditions at the start and end of
the file), but something close to it.

     Just goes to show that few dumb ideas are so dumb
as to escape implementation somewhere, somehow.  Something
to keep in mind when evaluating a claim that begins
"Nobody would be silly enough to ..."

It lives on in SGML 'records'.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top