fseek

[Dan Pop]

Re: fseek

In <l6j4rvcu495gj0 a4cebt3btuo42v7 d1oq1@4ax.com> Alan Balmer <albalmer@att.n et> writes:
[color=blue]
>On 12 Nov 2003 13:25:17 GMT, Dan.Pop@cern.ch (Dan Pop) wrote:
>[color=green][color=darkred]
>>>7.19.9.2
>>>
>>>"For a text stream, either offset shall be zero, or offset shall be a
>>>value returned by an _earlier successful call to the ftell function on
>>>a stream associated with the same file_ and whence shall be SEEK_SET."
>>>
>>>Emphasis added.[/color]
>>
>>The other stream *must* be a text stream too. Connect a binary stream to
>>a text file and all the bets are off.[/color]
>
>Chapter and verse, please.[/color]

It's an obvious bug in the standard. Ask in comp.std.c if you don't
believe me.

Binary files and text files can have completely different internal
representations and the standard doesn't provide any guarantee about
what happens when you open a text file in binary mode or vice versa.
It only addresses the cases when a binary stream is attached to a binary
file and a text stream to a text file.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Eric Sosman]

Re: fseek

Dan Pop wrote:[color=blue]
>
> Binary files and text files can have completely different internal
> representations and the standard doesn't provide any guarantee about
> what happens when you open a text file in binary mode or vice versa.
> It only addresses the cases when a binary stream is attached to a binary
> file and a text stream to a text file.[/color]

I don't think the notions of "text file" and "binary
file" as disjoint categories will withstand scrutiny. At
least, I've never seen any attempted definitions that were
beyond reproach.

The Standard says very little about "text files" and
"binary files," and that seems a wise choice. About all
we can infer is that a "text file" is an entity suitable
for access via a text stream, while a "binary file" is
suited to binary streams. Some kinds of files may work
with both kinds of streams, and some kinds of files may
work with neither -- and the implementation' s whim rules
the day.

--
Eric.Sosman@sun .com

[Alan Balmer]

Re: fseek

On 12 Nov 2003 17:27:25 GMT, Dan.Pop@cern.ch (Dan Pop) wrote:
[color=blue]
>In <d8j4rvo967qj9j i44rdg02gsedred 00kpo@4ax.com> Alan Balmer <albalmer@att.n et> writes:
>[color=green]
>>On 12 Nov 2003 13:26:55 GMT, Dan.Pop@cern.ch (Dan Pop) wrote:
>>[color=darkred]
>>>>Which was exactly the point. There's more involved in seeking a text
>>>>stream than simply counting characters.
>>>
>>>And yet, you claim that you can use character offsets as arguments to a
>>>fseek call on a text stream.[/color]
>>
>>Of course you can. You can also use random numbers.[/color]
>
>The idea was to be able to seek to well defined positions inside the file.
>[color=green]
>>I don't claim to
>>be able to portably relate the results to anything in particular.[/color]
>
>In general, the results of ftell on a binary stream are
>useless/meaningless to any text stream on the same implementation.
>
>The thing you don't get is that the encoding of the file position returned
>by ftell on a text stream need not be a plain byte offset. It could be
>a record number and a byte offset inside the record.
>
>Dan[/color]
Sorry to dispell your illusion of omniscience (do you fancy yourself a
telepath?), but you have no idea what I "get" and "don't get." I not
only "get" that possibility, I have designed storage systems using
similar methodology. What *you* don't "get" (or at least want to argue
about) is that any file may be opened in binary mode, and a character
offset generated by fseek/ftell. The standard does not preclude using
that offset in fseek on a text file. Obviously, as I stated
previously, the standard says nothing about the usefulness of doing
this. You say this is an "obvious bug" in the standard. I suggest you
submit it for correction.

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Dan Pop]

Re: fseek

In <3FB2768F.A3DA6 4F2@sun.com> Eric Sosman <Eric.Sosman@su n.com> writes:
[color=blue]
>Dan Pop wrote:[color=green]
>>
>> Binary files and text files can have completely different internal
>> representations and the standard doesn't provide any guarantee about
>> what happens when you open a text file in binary mode or vice versa.
>> It only addresses the cases when a binary stream is attached to a binary
>> file and a text stream to a text file.[/color]
>
> I don't think the notions of "text file" and "binary
>file" as disjoint categories will withstand scrutiny. At
>least, I've never seen any attempted definitions that were
>beyond reproach.[/color]

In the context of the C programming language, a text file is a file
created via a text stream and a binary file is a file created via a
binary stream. No guarantees for files created by other means than
correct C programs.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Glen Herrmannsfeldt]

Re: fseek


"Dan Pop" <Dan.Pop@cern.c h> wrote in message
news:botuni$jr9 $2@sunnews.cern .ch...[color=blue]
> In <3FB2768F.A3DA6 4F2@sun.com> Eric Sosman <Eric.Sosman@su n.com> writes:[/color]

(snip)
[color=blue][color=green]
> > I don't think the notions of "text file" and "binary
> >file" as disjoint categories will withstand scrutiny. At
> >least, I've never seen any attempted definitions that were
> >beyond reproach.[/color]
>
> In the context of the C programming language, a text file is a file
> created via a text stream and a binary file is a file created via a
> binary stream. No guarantees for files created by other means than
> correct C programs.[/color]

That may be true, but I would be disappointed to find a system where reading
a C text file would not read text files commonly available on a system, such
as produced by the systems normal text editor(s).

For binary files, though, one may find that the only way to create a binary
file that C programs can read is one written by a C program. In many
languages, this is normal for binary files. In C it is often expected that
one can read any binary file, written by any program in any language, though
that may not be true on all systems.

Any system that normally stores text files using less than eight bits per
character would make it hard for text and binary files to be compatible.

-- glen

[lawrence.jones@eds.com]

Re: fseek

Alan Balmer <albalmer@att.n et> wrote:[color=blue]
>
> What *you* don't "get" (or at least want to argue
> about) is that any file may be opened in binary mode[/color]

That is true on many systems, but it is not guaranteed by the standard.

-Larry Jones

At times like these, all Mom can think of is how long she was in
labor with me. -- Calvin

[lawrence.jones@eds.com]

Re: fseek

Alan Balmer <albalmer@att.n et> wrote [quoting Dan Pop]:[color=blue]
>[color=green]
>>The other stream *must* be a text stream too. Connect a binary stream to
>>a text file and all the bets are off.[/color]
>
> Chapter and verse, please.[/color]

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.

-Larry Jones

In my opinion, we don't devote nearly enough scientific research
to finding a cure for jerks. -- Calvin

[Irrwahn Grausewitz]

Re: fseek

lawrence.jones@ eds.com wrote:
[color=blue]
> Alan Balmer <albalmer@att.n et> wrote [quoting Dan Pop]:[color=green]
> >[color=darkred]
> >>The other stream *must* be a text stream too. Connect a binary stream to
> >>a text file and all the bets are off.[/color]
> >
> > Chapter and verse, please.[/color]
>
> 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.[/color]

Seems to be the appropriate section, yes; but re-reading it I
stumbled over something I've overseen till now:

7.19.5.3p6
[...]
Opening (or creating) a text file with update mode may instead
open (or create) a binary stream in some implementations .

I'm not sure if this can be used to form an argument in the debate
about the relationship of binary and text files, and if so, pro or
contra which side; I'm just puzzled that such a strange behaviour
is sanctioned by the standard...

Regards
--
Irrwahn
(irrwahn33@free net.de)

[Alan Balmer]

Re: fseek

On Wed, 12 Nov 2003 23:13:01 GMT, lawrence.jones@ eds.com wrote:
[color=blue]
>Alan Balmer <albalmer@att.n et> wrote [quoting Dan Pop]:[color=green]
>>[color=darkred]
>>>The other stream *must* be a text stream too. Connect a binary stream to
>>>a text file and all the bets are off.[/color]
>>
>> Chapter and verse, please.[/color]
>
>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.
>[/color]
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.

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 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.

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

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Alan Balmer]

Re: fseek

On Wed, 12 Nov 2003 23:13:01 GMT, lawrence.jones@ eds.com wrote:
[color=blue]
>Alan Balmer <albalmer@att.n et> wrote:[color=green]
>>
>> What *you* don't "get" (or at least want to argue
>> about) is that any file may be opened in binary mode[/color]
>
>That is true on many systems, but it is not guaranteed by the standard.
>[/color]
Nor is it prohibited by the standard.

Name me a system where it can't be done.

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Glen Herrmannsfeldt]

Re: fseek


"Alan Balmer" <albalmer@att.n et> wrote in message
news:bdg5rv4p9v o2rar43m5kk4a2l h7viaq338@4ax.c om...[color=blue]
> On Wed, 12 Nov 2003 23:13:01 GMT, lawrence.jones@ eds.com wrote:
>[color=green]
> >Alan Balmer <albalmer@att.n et> wrote [quoting Dan Pop]:[color=darkred]
> >>
> >>>The other stream *must* be a text stream too. Connect a binary stream[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >>>a text file and all the bets are off.
> >>
> >> Chapter and verse, please.[/color]
> >
> >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.
> >[/color]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Perhaps Dan is right, and the writers made a mistake. I'm in no
> position to make a judgment on that.[/color]

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

[Dan Pop]

Re: fseek

In <p7ysb.134611$2 75.397546@attbi _s53> "Glen Herrmannsfeldt" <gah@ugcs.calte ch.edu> writes:

[color=blue]
>"Dan Pop" <Dan.Pop@cern.c h> wrote in message
>news:botuni$jr 9$2@sunnews.cer n.ch...[color=green]
>> In <3FB2768F.A3DA6 4F2@sun.com> Eric Sosman <Eric.Sosman@su n.com> writes:[/color]
>
>(snip)
>[color=green][color=darkred]
>> > I don't think the notions of "text file" and "binary
>> >file" as disjoint categories will withstand scrutiny. At
>> >least, I've never seen any attempted definitions that were
>> >beyond reproach.[/color]
>>
>> In the context of the C programming language, a text file is a file
>> created via a text stream and a binary file is a file created via a
>> binary stream. No guarantees for files created by other means than
>> correct C programs.[/color]
>
>That may be true, but I would be disappointed to find a system where reading
>a C text file would not read text files commonly available on a system, such
>as produced by the systems normal text editor(s).[/color]

There is nothing preventing the system's normal text editor(s) from being
written in C ;-) It's even current practice, these days.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: fseek

In <lph5rvgg55af1m odblq7c53emkljk c22lg@4ax.com> Alan Balmer <albalmer@att.n et> writes:
[color=blue]
>On Wed, 12 Nov 2003 23:13:01 GMT, lawrence.jones@ eds.com wrote:
>[color=green]
>>Alan Balmer <albalmer@att.n et> wrote:[color=darkred]
>>>
>>> What *you* don't "get" (or at least want to argue
>>> about) is that any file may be opened in binary mode[/color]
>>
>>That is true on many systems, but it is not guaranteed by the standard.
>>[/color]
>Nor is it prohibited by the standard.
>
>Name me a system where it can't be done.[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^
When you have to resort to Trollsdale favourite "argument", there *is*
something wrong with your position in the debate.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: fseek

In <XPEsb.134993$m Z5.932687@attbi _s54> "Glen Herrmannsfeldt" <gah@ugcs.calte ch.edu> writes:

[color=blue]
>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.[/color]

Then again, we have the DeathStation. Text files *must* have the .t
extension (otherwise fopen in text mode fails) and binary files *must*
have the .b extension (otherwise fopen in binary mode fails). Files with
other extensions cannot be opened. Neither rename() nor any system
utility allows changing the file's extension. Perfectly allowed by the
standard.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Alan Balmer]

Re: fseek

On Thu, 13 Nov 2003 00:34:22 +0100, Irrwahn Grausewitz
<irrwahn33@free net.de> wrote:
[color=blue]
>lawrence.jones @eds.com wrote:
>[color=green]
>> Alan Balmer <albalmer@att.n et> wrote [quoting Dan Pop]:[color=darkred]
>> >
>> >>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.[/color]
>>
>> 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.[/color]
>
>Seems to be the appropriate section, yes; but re-reading it I
>stumbled over something I've overseen till now:
>
> 7.19.5.3p6
> [...]
> Opening (or creating) a text file with update mode may instead
> open (or create) a binary stream in some implementations .
>
>I'm not sure if this can be used to form an argument in the debate
>about the relationship of binary and text files, and if so, pro or
>contra which side; I'm just puzzled that such a strange behaviour
>is sanctioned by the standard...
>
>Regards[/color]

Like you, I don't know that it's pertinent to the current discussion,
but it is interesting, and rather oddly tucked in to the section. An
afterthought to cover some actual implementation?

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net