Re: fseek

From: Glen Herrmannsfeldt (gah_at_ugcs.caltech.edu)
Date: 11/13/03 

Date: Thu, 13 Nov 2003 05:41:11 GMT

"Alan Balmer" <albalmer@att.net> wrote in message
news:bdg5rv4p9vo2rar43m5kk4a2lh7viaq338@4ax.com...
> On Wed, 12 Nov 2003 23:13:01 GMT, lawrence.jones@eds.com wrote:
>
> >Alan Balmer <albalmer@att.net> wrote [quoting Dan Pop]:
> >>
> >>>The other stream *must* be a text stream too. Connect a binary stream
to
> >>>a text file and all the bets are off.
> >>
> >> Chapter and verse, please.
> >
> >See 7.19.5.3 (fopen) -- the standard does not provide any way to connect
> >a text stream to a binary file or vice versa. Attempting to open a
> >binary file in text mode or vice versa results in undefined behavior.
> >
> This paragraph only describes the mode that the stream is opened in,
> saying nothing about the files themselves. It does not say that
> opening a file in the "wrong" mode results in undefined behavior. The
> mode is important to the user, since in text mode it tells the I/O
> implementation that it must look for, and possibly map, newline
> characters. In binary mode, newline characters are treated the same as
> any other character.

Newline conversion is one of the common changes, but not the only one.

 The PDP-10 (TOPS-10 and TOPS-20 OS) store text files as five 7 bit ASCII
characters per word. A possible binary format is four 9 bit char's per
word. The results will be very different if the wrong one is used.

CDC had a series of machines with 60 bit words, which used either 6 or 12
bits per character, depending on the bit patterns. (Similar to UTF-8
coding, where some bits indicate the length.) I don't know what CHAR_BIT
might be, though. In this case, with variable length characters, or for
that matter with UTF-8, one can imagine that text streams and binary
streams would work differently.

> Opening a text file in binary mode is perfectly legitimate - in fact
> the standard provides no way to distinguish between a binary file and
> a text file. Refer to 17.19.2, where the two types of streams are
> defined. Now, consider a "text" file containing one "line." The thing
> that makes it a text file is that each "line" has a terminating
> newline character. But the standard says that the last line need not
> have the terminating newline (it's implementation dependent.) How can
> this file be distinguished from a binary file? What will the
> implementation do to me if I open it in binary mode?

On IBM's mainframe OSs lines never have newline characters on them, though
they could contain newline characters.

There could be systems that keep text and binary files completely separate,
such that no operations are allowed on the wrong type. I don't know of any,
though.

> On the other hand, presume that I have a binary file, say an
> executable program. This file may contain numerous instances of a
> character with the value 0xA, which happens to be the newline
> character on the system I'm using now. Does that make it a text file?
> Obviously not, but it may meet all the criteria for opening as a text
> stream.

I have heard about people trying to make executable text files on various
systems. That is, only opcodes that are printable characters are allowed.
Very strange, but some systems allow it.

> Perhaps Dan is right, and the writers made a mistake. I'm in no
> position to make a judgment on that.

The standard tries to allow for reasonable differences in hardware, OS, and
file system design. Many features are to accommodate features of existing
systems, or ones that existed in the past.

-- glen

Relevant Pages

  • Re: Reading and writing a large binary file fails
    ... So it's a binary file - and doesn't contain meaningful text. ... Reads characters from the underlying stream and advances the current ... This reads *characters* according to the encoding associated with the ... To reduce fragmentation, you may want to extend your target file by ...
    (microsoft.public.dotnet.framework)
  • Re: Why does FILE-LENGTH take a stream rather a pathname?
    ... >> and getting the information from the stream. ... binary file length. ... files that are not character files? ... nothing really relates file positions with file lenghts. ...
    (comp.lang.lisp)
  • Re: Replacing characters in file
    ... Well, if it is not a text file but a binary file, then it isn't very ... meaningful to talk about characters. ... Computers are notorious at being extremely pedantic. ... It doesn't work in SED because SED aborts when it hits the first EOF ...
    (comp.lang.perl.misc)
  • Re: replacing text data in a binary file
    ... &HFF for the byte. ... That explains the cbyte in ... >> If you are editing a binary file I would recommend opening the file with ... >> removing or adding characters may actually corrupt the file, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Replacing characters in file
    ... Well, if it is not a text file but a binary file, then it isn't very ... meaningful to talk about characters. ... It doesn't work in SED because SED aborts when it hits the first EOF ... downloading Active Perl and see what happens there, ...
    (comp.lang.perl.misc)