Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > text and binary streams

Reply
Thread Tools

text and binary streams

 
 
subramanian100in@yahoo.com, India
Guest
Posts: n/a
 
      08-23-2008
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
 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      08-23-2008
In article <(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed), India <(E-Mail Removed)> wrote:

>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
--
Please remember to mention me / in tapes you leave behind.
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      08-23-2008
(E-Mail Removed), India wrote:
> 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.
 
Reply With Quote
 
Herbert Rosenau
Guest
Posts: n/a
 
      08-24-2008
On Sun, 24 Aug 2008 03:36:46 UTC, Jack Klein <(E-Mail Removed)>
wrote:

>
> 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!
 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      08-24-2008
Eric Sosman <(E-Mail Removed)> wrote:
> Jack Klein wrote:
> > [... 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'.

--
Peter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
streams binary and text Bill Cunningham C Programming 4 08-29-2012 07:51 PM
Binary vs. formatted std::string reading/writing to streams Leslaw Bieniasz C++ 2 01-15-2010 11:53 PM
Efficient processing of binary data streams in Ruby? theosib@gmail.com Ruby 2 03-09-2007 03:10 AM
Dual binary/character streams? Adam Warner Java 18 11-08-2005 02:57 AM
Detecting binary verses text file streams Tron Thomas C++ 3 11-08-2004 10:07 PM



Advertisments