text and binary streams

Discussion in 'C Programming' started by subramanian100in@yahoo.com, India, Aug 23, 2008.

  1. , India

    , India Guest

    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
     
    , India, Aug 23, 2008
    #1
    1. Advertising

  2. In article <>,
    , 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" ?


    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.
     
    Richard Tobin, Aug 23, 2008
    #2
    1. Advertising

  3. , India

    James Kuyper Guest

    , 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.
     
    James Kuyper, Aug 23, 2008
    #3
  4. On Sun, 24 Aug 2008 03:36:46 UTC, Jack Klein <>
    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!
     
    Herbert Rosenau, Aug 24, 2008
    #4
  5. Eric Sosman <> 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
     
    Peter Nilsson, Aug 25, 2008
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Adam Warner

    Dual binary/character streams?

    Adam Warner, Nov 6, 2005, in forum: Java
    Replies:
    18
    Views:
    1,046
    Roedy Green
    Nov 8, 2005
  2. Tron Thomas
    Replies:
    3
    Views:
    522
    Tron Thomas
    Nov 8, 2004
  3. Leslaw Bieniasz
    Replies:
    2
    Views:
    1,086
    Thomas J. Gritzan
    Jan 15, 2010
  4. Replies:
    2
    Views:
    266
  5. Bill Cunningham

    streams binary and text

    Bill Cunningham, Aug 29, 2012, in forum: C Programming
    Replies:
    4
    Views:
    395
    Ben Bacarisse
    Aug 29, 2012
Loading...

Share This Page