On thinking about the "replace a word in a file" thread, I wondered how easy
it would be to accomplish the same thing with only one file pointer. This led
me to some questions...
"For a text stream, offset must be zero, or a value returned by ftell (in
which case origin must be SEEK_SET)."
If offset is a value returned by ftell (which returns the current file
position), and origin is SEEK_SET, then fseek() sets the position to the
current position. What is the point of doing so? And, more importantly, why
can't text streams be fseek()'ed randomly like a binary stream can (i.e.,
offset can be any number of bytes)? Do I understand this paragraph correctly?
If so, can fgetpos() and fsetpos() be used to approximate fseek() for text
streams?
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
62  6137 
Christopher Benson-Manica wrote: "For a text stream, offset must be zero, or a value returned by ftell (in
which case origin must be SEEK_SET)."
If offset is a value returned by ftell (which returns the current file
position), and origin is SEEK_SET, then fseek() sets the position to the
current position. What is the point of doing so? And, more importantly, why
It seems to make more sense if you read that as
"or a value previously returned by ftell," so you
may save the ftell value and use it later.
--
Michael
mf <mf@dcs.warwick.ac.uk> spoke thus: It seems to make more sense if you read that as
"or a value previously returned by ftell," so you
may save the ftell value and use it later.
Aahh... ;( Now *that* makes more sense. Still, why the restriction? Or
rather, why do binary streams get to seek whereever they want, while text
streams are constrained to be proper and seek to someplace that was at least
valid at some point in the past? Maybe I should just go home, eh? ;)
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Christopher Benson-Manica wrote:
mf <mf@dcs.warwick.ac.uk> spoke thus:
It seems to make more sense if you read that as
"or a value previously returned by ftell," so you
may save the ftell value and use it later.
Aahh... ;( Now *that* makes more sense. Still, why the restriction? Or
rather, why do binary streams get to seek whereever they want, while text
streams are constrained to be proper and seek to someplace that was at least
valid at some point in the past? Maybe I should just go home, eh? ;)
Usually, people who wonder about this are thinking of
trying to fseek() to an arithmetically-calculated position
in the file: so-and-so many characters before or after such-
and-such a position. But how should this new position be
defined? Where should fseek(stream, 1000, SEEK_SET) land?
- The same position you'd reach by starting at the
beginning and doing getc(stream) 1000 times? This
might take just as long as doing the getc()s, if
there's no way to calculate the destination. For
example, consider reading an MS-DOS file, where
pairs of CR/LF must be translated to single '\n'
characters; the proper destination depends on how
many such pairs are skipped over, and that may not
be knowable without actually reading them.
- 1000 bytes from the start of the file? That might
not even be a valid character position at all; it
might not be possible to arrive at that position
by repeated getc()s. For example, consider reading
an OpenVMS VAR file, where each line consists of a
two-byte count, a "payload," and a possible padding
bytes. Some of those bytes have no "image" in the
data getc() can read, conversely, the '\n' characters
returned by getc() do not actually exist in the file.
There are lots and lots of file organizations out there,
and a requirement to support arbitrary seeking in text streams
would make efficient C implementations difficult or impossible.
One of the reasons fgetpos() and fsetpos() were created was
to give better support to file systems less simple than those
C grew up with.
-- Er*********@sun.com
On Fri, 07 Nov 2003 19:41:27 +0000, Christopher Benson-Manica wrote: On thinking about the "replace a word in a file" thread, I wondered how easy
it would be to accomplish the same thing with only one file pointer. This led
me to some questions...
"For a text stream, offset must be zero, or a value returned by ftell (in
which case origin must be SEEK_SET)."
If offset is a value returned by ftell (which returns the current file
position), and origin is SEEK_SET, then fseek() sets the position to the
current position. What is the point of doing so?
The value returned by ftell could have been from earlier:
get position
read
read
read
seek back to saved position
And, more importantly, why
can't text streams be fseek()'ed randomly like a binary stream can
Try this:
File x contains a series of chars '0', '1', '2' and so on, up to '9'.
Between each is written a "CRLF". In text mode, "CRLF"is treated as "\n"
on read, despite being two bytes in the file and only one after conversion.
Now, when attempting to seek to position n in the file... where n is
specified in "bytes from start of file"... exactly how many such "CRLF"
pairs are there to cope with and how should the offset be altered as a
result? After all, if I fgetc 9 times, the 10th will produce a specific
result; if I fseek to the 10th position and fgetc, I should get the same
result, no? But that would mean that fseek needs to figure out, on the
fly, the contents of the file and what transformations would be done. If
nothing else, it would be hellishly inefficient.
Eric Sosman <Er*********@sun.com> spoke thus: Usually, people who wonder about this are thinking of
trying to fseek() to an arithmetically-calculated position
in the file: so-and-so many characters before or after such-
and-such a position. But how should this new position be
defined? Where should fseek(stream, 1000, SEEK_SET) land?
Ah, I see now. Far be it from me to inconvenience implementors... ;)
Thanks.
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
On Mon, 10 Nov 2003 12:44:40 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote: Eric Sosman <Er*********@sun.com> spoke thus:
Usually, people who wonder about this are thinking of
trying to fseek() to an arithmetically-calculated position
in the file: so-and-so many characters before or after such-
and-such a position. But how should this new position be
defined? Where should fseek(stream, 1000, SEEK_SET) land?
Ah, I see now. Far be it from me to inconvenience implementors... ;)
Thanks.
It's a bit more than that. How do you seek past a newline if you're
counting bytes?
--
Al Balmer
Balmer Consulting re************************@att.net
"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bo**********@chessie.cirr.com... Eric Sosman <Er*********@sun.com> spoke thus:
Usually, people who wonder about this are thinking of
trying to fseek() to an arithmetically-calculated position
in the file: so-and-so many characters before or after such-
and-such a position. But how should this new position be
defined? Where should fseek(stream, 1000, SEEK_SET) land?
Ah, I see now. Far be it from me to inconvenience implementors... ;)
It is not so much the implementors convenience. The idea of fseek() is to
move the pointer without reading all the characters in between. C already
supplies ways to read all the characters, if you want to do that.
-- glen
Alan Balmer wrote:
On Mon, 10 Nov 2003 12:44:40 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote:
Eric Sosman <Er*********@sun.com> spoke thus:
Usually, people who wonder about this are thinking of
trying to fseek() to an arithmetically-calculated position
in the file: so-and-so many characters before or after such-
and-such a position. But how should this new position be
defined? Where should fseek(stream, 1000, SEEK_SET) land?
Ah, I see now. Far be it from me to inconvenience implementors... ;)
Thanks.
It's a bit more than that. How do you seek past a newline if you're
counting bytes?
Is this a trick question? What does seeking have to do with counting
bytes? What does 'seeking past a newline' mean? If you are counting
bytes and discover a '\n' you might perform an ftell(stream) and save
the result in a long. This will be the address that you can eventually
pass to fseek() to arrive at the place you are now, one past the '\n'.
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
"Joe Wright" <jo********@earthlink.net> wrote in message
news:3F***********@earthlink.net... Alan Balmer wrote:
On Mon, 10 Nov 2003 12:44:40 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote:
Eric Sosman <Er*********@sun.com> spoke thus: Usually, people who wonder about this are thinking of
> trying to fseek() to an arithmetically-calculated position
> in the file: so-and-so many characters before or after such-
> and-such a position. But how should this new position be
> defined? Where should fseek(stream, 1000, SEEK_SET) land?
Ah, I see now. Far be it from me to inconvenience implementors... ;)
Thanks.
It's a bit more than that. How do you seek past a newline if you're
counting bytes?
Is this a trick question? What does seeking have to do with counting
bytes? What does 'seeking past a newline' mean? If you are counting
bytes and discover a '\n' you might perform an ftell(stream) and save
the result in a long. This will be the address that you can eventually
pass to fseek() to arrive at the place you are now, one past the '\n'.
Seek, such as fseek(), puts the file position pointer at the specified
position in the file. In a file format with multiple line end characters,
all will be represented by a single '\n' to a program counting getc() calls
within a loop. If one expected the positions returned by ftell() or used
by fseek() to match those from counting getc() calls, the only
implementation for fseek() would be to read from the beginning of the file
while counting '\r' characters that are followed by '\n'.
The problem gets worse for the file format used by many IBM mainframe OSs.
The number of records in a block, or blocks on a disk track are not
necessarily knowable. In that case, pretty much the only solution is to
read every block from the
beginning, though it does not need to examine every byte that is read.
(For a file written on only once, it should be possible to seek by track and
block. If a file is closed, reopened, and then appended, there might be
short blocks in the middle of the file. There is no other way to account
for them.)
-- glen
On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote: It's a bit more than that. How do you seek past a newline if you're
counting bytes?
Is this a trick question? What does seeking have to do with counting
bytes?
The offset parameter of fseek is in bytes.
What does 'seeking past a newline' mean?
The number of bytes in a newline is platform dependent.
--
Al Balmer
Balmer Consulting re************************@att.net
Alan Balmer <al******@att.net> wrote: On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote:
It's a bit more than that. How do you seek past a newline if you're
counting bytes?
Is this a trick question? What does seeking have to do with counting
bytes?
The offset parameter of fseek is in bytes.
Only for a binary stream.
Richard
On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote: Alan Balmer <al******@att.net> wrote:
On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote:
>> It's a bit more than that. How do you seek past a newline if you're
>> counting bytes?
>>
>Is this a trick question? What does seeking have to do with counting
>bytes?
The offset parameter of fseek is in bytes.
Only for a binary stream.
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
--
Al Balmer
Balmer Consulting re************************@att.net
Alan Balmer <al******@att.net> wrote: On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
Alan Balmer <al******@att.net> wrote:
On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote:
>> It's a bit more than that. How do you seek past a newline if you're
>> counting bytes?
>>
>Is this a trick question? What does seeking have to do with counting
>bytes?
The offset parameter of fseek is in bytes.
Only for a binary stream.
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
Erm... how? AFAIAA, the results of an fseek() on a file opened as a
binary stream do not have to be relevant to the same file opened as a
text stream.
Richard
In <q2********************************@4ax.com> Alan Balmer <al******@att.net> writes: On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote:
It's a bit more than that. How do you seek past a newline if you're
counting bytes?
Is this a trick question? What does seeking have to do with counting
bytes?
The offset parameter of fseek is in bytes.
Wrong on text streams, where it is in an unspecified unit. What does 'seeking past a newline' mean?
The number of bytes in a newline is platform dependent.
Entirely irrelevant, for both kind of streams. If you attach a binary
stream to a text file, all the bets are off: you may not see a single
newline character in the whole file (implementations storing each line
of text in a variable size record typically don't bother to store the
newline character at all: it is implied, after the last character of the
record).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <b2********************************@4ax.com> Alan Balmer <al******@att.net> writes: On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
Alan Balmer <al******@att.net> wrote:
On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote:
>> It's a bit more than that. How do you seek past a newline if you're
>> counting bytes?
>>
>Is this a trick question? What does seeking have to do with counting
>bytes?
The offset parameter of fseek is in bytes.
Only for a binary stream.
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
Where did you get the idea from? Chapter and verse, please.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Alan Balmer <al******@att.net> wrote: On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
Alan Balmer <al******@att.net> wrote:
On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote:
>> It's a bit more than that. How do you seek past a newline if you're
>> counting bytes?
>>
>Is this a trick question? What does seeking have to do with counting
>bytes?
The offset parameter of fseek is in bytes.
Only for a binary stream.
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
AFAICT: no, you can't. Hence the restriction for using fseek() on
text streams:
ISO/IEC 9899:TC1 7.19.9.2#4
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.
Well, it says not explicitly: "a stream associated with the same file
opened in the same (text) mode", but the C-Rationale explains:
"Whereas a binary file can be treated as an ordered sequence of bytes
counting from zero, a text file need not map one-to-one to its
internal representation (see 7.19.2). Thus, only seeks to an earlier
reported position are permitted for text files. [...]"
Therefore I don't think the procedure you suggested will work
portably.
Regards
--
Irrwahn
(ir*******@freenet.de)
"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:38********************************@4ax.com... Alan Balmer <al******@att.net> wrote: On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
(snip)
> The offset parameter of fseek is in bytes.
Only for a binary stream.
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
AFAICT: no, you can't. Hence the restriction for using fseek() on
text streams:
ISO/IEC 9899:TC1 7.19.9.2#4
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.
Well, it says not explicitly: "a stream associated with the same file
opened in the same (text) mode", but the C-Rationale explains:
"Whereas a binary file can be treated as an ordered sequence of bytes
counting from zero, a text file need not map one-to-one to its
internal representation (see 7.19.2). Thus, only seeks to an earlier
reported position are permitted for text files. [...]"
Therefore I don't think the procedure you suggested will work
portably.
I am not sure now of the status of C compilers for the PDP-10, but the
normal text file format has five ASCII characters per 36 bit word. A
possible C compatible binary format would have four 9 bit bytes per word.
That would make things extrememly complicated using fseek() between text and
binary files.
-- glen
"Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> wrote:
"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:38********************************@4ax.com... Alan Balmer <al******@att.net> wrote: On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
(snip)
> The offset parameter of fseek is in bytes.
>
>Only for a binary stream.
>
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
AFAICT: no, you can't. Hence the restriction for using fseek() on
text streams:
ISO/IEC 9899:TC1 7.19.9.2#4
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.
Well, it says not explicitly: "a stream associated with the same file
opened in the same (text) mode", but the C-Rationale explains:
"Whereas a binary file can be treated as an ordered sequence of bytes
counting from zero, a text file need not map one-to-one to its
internal representation (see 7.19.2). Thus, only seeks to an earlier
reported position are permitted for text files. [...]"
Therefore I don't think the procedure you suggested will work
portably.
I am not sure now of the status of C compilers for the PDP-10, but the
normal text file format has five ASCII characters per 36 bit word. A
possible C compatible binary format would have four 9 bit bytes per word.
That would make things extrememly complicated using fseek() between text and
binary files.
Indeed. And it leads to this (again, quoting the C-Rationale):
"The need to encode both record position and position within a record
in a long value may constrain the size of text files upon which fseek
and ftell can be used to be considerably smaller than the size of
binary files."
--
Irrwahn
(ir*******@freenet.de)
On 11 Nov 2003 17:02:25 GMT, Da*****@cern.ch (Dan Pop) wrote: In <b2********************************@4ax.com> Alan Balmer <al******@att.net> writes:
On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
Alan Balmer <al******@att.net> wrote:
On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
<jo********@earthlink.net> wrote:
>> It's a bit more than that. How do you seek past a newline if you're
>> counting bytes?
>>
>Is this a trick question? What does seeking have to do with counting
>bytes?
The offset parameter of fseek is in bytes.
Only for a binary stream.
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
Where did you get the idea from? Chapter and verse, please.
Dan
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.
--
Al Balmer
Balmer Consulting re************************@att.net
On 11 Nov 2003 16:45:32 GMT, Da*****@cern.ch (Dan Pop) wrote: What does 'seeking past a newline' mean?
The number of bytes in a newline is platform dependent.
Entirely irrelevant, for both kind of streams. If you attach a binary
stream to a text file, all the bets are off: you may not see a single
newline character in the whole file (implementations storing each line
of text in a variable size record typically don't bother to store the
newline character at all: it is implied, after the last character of the
record).
Which was exactly the point. There's more involved in seeking a text
stream than simply counting characters. In other words, the OP's
implication that the different treatment of text streams in the
standard is simply an "inconvenience" to implementors is incorrect.
Not irrelevant at all
--
Al Balmer
Balmer Consulting re************************@att.net
On Tue, 11 Nov 2003 20:37:45 +0100, Irrwahn Grausewitz
<ir*******@freenet.de> wrote: > 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.
>
> Well, it says not explicitly: "a stream associated with the same file
> opened in the same (text) mode", but the C-Rationale explains:
Quite right. It does not say that. If the writers had wanted to say
that, I suspect they would have. >
> "Whereas a binary file can be treated as an ordered sequence of bytes
> counting from zero, a text file need not map one-to-one to its
> internal representation (see 7.19.2). Thus, only seeks to an earlier
> reported position are permitted for text files. [...]"
And neither does this. However, this does say explicitly what I was
trying to convey to the OP. Thank you. >
> Therefore I don't think the procedure you suggested will work
> portably.
Depends on what you mean by "work." I would expect it to "work" on
any implementation. I wouldn't, however, try to predict the
relationship between a given offset in a binary file and the same
offset in a text file.
I don't have a long list of applications for the procedure, either,
but I don't see that it's prohibited by the standard.
Remember that the difference between text files and binary files (if
any) is a characteristic of the implementation. Text files can always
be treated as binary files, but the reverse is not generally true, and
even if you know it's a text file, interpreting it as text from a
binary stream is not portable.
--
Al Balmer
Balmer Consulting re************************@att.net
Alan Balmer <al******@att.net> wrote: On Tue, 11 Nov 2003 20:37:45 +0100, Irrwahn Grausewitz <ir*******@freenet.de> wrote:
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.
>
> Well, it says not explicitly: "a stream associated with the same file
> opened in the same (text) mode", but the C-Rationale explains:
Quite right. It does not say that. If the writers had wanted to say
that, I suspect they would have.
Maybe someone would like to generate a DR about this.
> "Whereas a binary file can be treated as an ordered sequence of bytes
> counting from zero, a text file need not map one-to-one to its
> internal representation (see 7.19.2). Thus, only seeks to an earlier
> reported position are permitted for text files. [...]"
And neither does this.
Not explicitly, but IMHO implicitly. Otherwise the "Thus, ..." part
makes no sense. However, it's quoted from the Rationale, not the
Standard.
However, this does say explicitly what I was
trying to convey to the OP. Thank you.
> Therefore I don't think the procedure you suggested will work
> portably.
Depends on what you mean by "work." I would expect it to "work" on
any implementation. I wouldn't, however, try to predict the
relationship between a given offset in a binary file and the same
offset in a text file.
That's an, err, interesting definition of "work". Anyway, if you are
aware of these facts, why did you suggest upthread:
AB> However, you can open the same file as binary, then use the
AB> results of fseek and ftell to position the text file.
as if this procedure would do anything useful?
IOW: you at least forgot to add a disclaimer. ;-)
Regards
--
Irrwahn
(ir*******@freenet.de)
On Wed, 12 Nov 2003 01:16:36 +0100, Irrwahn Grausewitz
<ir*******@freenet.de> wrote: Depends on what you mean by "work." I would expect it to "work" on
any implementation. I wouldn't, however, try to predict the
relationship between a given offset in a binary file and the same
offset in a text file.
That's an, err, interesting definition of "work".
What's yours?
You can write the code, any compiler should compile it, and you can
execute it. It will work, whether the results are useful or not. I
wish that I could claim that all the work I've ever done turned out to
be useful ;-)
Anyway, if you are
aware of these facts, why did you suggest upthread:
AB> However, you can open the same file as binary, then use the
AB> results of fseek and ftell to position the text file.
as if this procedure would do anything useful?
IOW: you at least forgot to add a disclaimer. ;-)
It wasn't a suggestion, but a comment. After all, the OP wasn't
looking for suggestions, but commenting on how he thought things
*should* work, as opposed to how they *do* work.
In the course of the thread, someone brought up the fact that offsets
are counted as characters for binary files, but nothing in particular
for text files. While commenting on that, I mentioned that a file can
be opened and positioned as binary, and that the standard apparently
allows that position to be used in fseek for the same file opened as
text. I find that interesting, and could probably even invent a
legitimate use for it (investigating the actual structure of a text
file, perhaps.)
I suggest that you reread the thread from the beginning, remembering
that my prose generation is not always the best, and I may sometimes
mistakenly assume that the reader is thinking in the same twisted
direction that I am :-)
--
Al Balmer
Balmer Consulting re************************@att.net
Alan Balmer <al******@att.net> wrote:
<snip> I suggest that you reread the thread from the beginning, remembering
that my prose generation is not always the best, and I may sometimes
mistakenly assume that the reader is thinking in the same twisted
direction that I am :-)
The root of misinterpretation that may be, yes :-)
--
Irrwahn
(ir*******@freenet.de)
In <35********************************@4ax.com> Alan Balmer <al******@att.net> writes: On 11 Nov 2003 17:02:25 GMT, Da*****@cern.ch (Dan Pop) wrote:
In <b2********************************@4ax.com> Alan Balmer <al******@att.net> writes:
On Tue, 11 Nov 2003 13:42:50 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
Alan Balmer <al******@att.net> wrote:
> On Tue, 11 Nov 2003 00:24:47 GMT, Joe Wright
> <jo********@earthlink.net> wrote:
>
> >> It's a bit more than that. How do you seek past a newline if you're
> >> counting bytes?
> >>
> >Is this a trick question? What does seeking have to do with counting
> >bytes?
>
> The offset parameter of fseek is in bytes.
Only for a binary stream.
True - the standard does not define the units for text streams (though
it's still bytes in at least some implementations.) However, you can
open the same file as binary, then use the results of fseek and ftell
to position the text file.
Where did you get the idea from? Chapter and verse, please.
Dan
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.
The other stream *must* be a text stream too. Connect a binary stream to
a text file and all the bets are off.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <vg********************************@4ax.com> Alan Balmer <al******@att.net> writes: On 11 Nov 2003 16:45:32 GMT, Da*****@cern.ch (Dan Pop) wrote:
What does 'seeking past a newline' mean?
The number of bytes in a newline is platform dependent.
Entirely irrelevant, for both kind of streams. If you attach a binary
stream to a text file, all the bets are off: you may not see a single
newline character in the whole file (implementations storing each line
of text in a variable size record typically don't bother to store the
newline character at all: it is implied, after the last character of the
record).
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.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On 12 Nov 2003 13:25:17 GMT, Da*****@cern.ch (Dan Pop) wrote: 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.
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.
--
Al Balmer
Balmer Consulting re************************@att.net
On 12 Nov 2003 13:26:55 GMT, Da*****@cern.ch (Dan Pop) wrote: 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.
Of course you can. You can also use random numbers. I don't claim to
be able to portably relate the results to anything in particular.
--
Al Balmer
Balmer Consulting re************************@att.net
In <d8********************************@4ax.com> Alan Balmer <al******@att.net> writes: On 12 Nov 2003 13:26:55 GMT, Da*****@cern.ch (Dan Pop) wrote:
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.
Of course you can. You can also use random numbers.
The idea was to be able to seek to well defined positions inside the file.
I don't claim to
be able to portably relate the results to anything in particular.
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <l6********************************@4ax.com> Alan Balmer <al******@att.net> writes: On 12 Nov 2003 13:25:17 GMT, Da*****@cern.ch (Dan Pop) wrote:
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.
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.
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: Da*****@ifh.de
Dan Pop wrote:
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.
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.
-- Er*********@sun.com
On 12 Nov 2003 17:27:25 GMT, Da*****@cern.ch (Dan Pop) wrote: In <d8********************************@4ax.com> Alan Balmer <al******@att.net> writes:
On 12 Nov 2003 13:26:55 GMT, Da*****@cern.ch (Dan Pop) wrote:
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.
Of course you can. You can also use random numbers.
The idea was to be able to seek to well defined positions inside the file.
I don't claim to
be able to portably relate the results to anything in particular.
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
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 re************************@att.net
In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes: Dan Pop wrote:
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.
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.
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: Da*****@ifh.de
"Dan Pop" <Da*****@cern.ch> wrote in message
news:bo**********@sunnews.cern.ch... In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:
(snip) 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.
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.
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
Alan Balmer <al******@att.net> wrote:
What *you* don't "get" (or at least want to argue
about) is that any file may be opened in binary mode
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
Alan Balmer <al******@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.
-Larry Jones
In my opinion, we don't devote nearly enough scientific research
to finding a cure for jerks. -- Calvin la************@eds.com wrote: Alan Balmer <al******@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.
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
(ir*******@freenet.de)
On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote: Alan Balmer <al******@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.
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 re************************@att.net
On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote: Alan Balmer <al******@att.net> wrote:
What *you* don't "get" (or at least want to argue
about) is that any file may be opened in binary mode
That is true on many systems, but it is not guaranteed by the standard.
Nor is it prohibited by the standard.
Name me a system where it can't be done.
--
Al Balmer
Balmer Consulting re************************@att.net
"Alan Balmer" <al******@att.net> wrote in message
news:bd********************************@4ax.com... On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote:
Alan Balmer <al******@att.net> wrote [quoting Dan Pop]:
The other stream *must* be a text stream too. Connect a binary stream
toa 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
In <p7ysb.134611$275.397546@attbi_s53> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes: "Dan Pop" <Da*****@cern.ch> wrote in message
news:bo**********@sunnews.cern.ch... In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:
(snip)
> 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.
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.
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).
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: Da*****@ifh.de
In <lp********************************@4ax.com> Alan Balmer <al******@att.net> writes: On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote:
Alan Balmer <al******@att.net> wrote:
What *you* don't "get" (or at least want to argue
about) is that any file may be opened in binary mode
That is true on many systems, but it is not guaranteed by the standard.
Nor is it prohibited by the standard.
Name me a system where it can't be done.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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: Da*****@ifh.de
In <XPEsb.134993$mZ5.932687@attbi_s54> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes: 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.
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: Da*****@ifh.de
On Thu, 13 Nov 2003 00:34:22 +0100, Irrwahn Grausewitz
<ir*******@freenet.de> wrote: la************@eds.com wrote:
Alan Balmer <al******@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.
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
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 re************************@att.net
On Thu, 13 Nov 2003 05:41:11 GMT, "Glen Herrmannsfeldt"
<ga*@ugcs.caltech.edu> wrote:
"Alan Balmer" <al******@att.net> wrote in message
news:bd********************************@4ax.com.. . On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote:
>Alan Balmer <al******@att.net> wrote [quoting Dan Pop]:
>>
<snip> 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.
It really doesn't matter -the standard refers to streams, not the
physical implementation. Both binary and text streams are a sequence
of characters as far as the standard is concerned. You ask for a
character, the system must do whatever is necessary to provide one.
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.
I wrote programs to convert tapes from those 60-bit CDC machines :-)
That wasn't the only strange thing - as I recall they would split data
at the end of a record.
However, I don't think a C implementation would provide variable
length characters, in spite of the hardware. 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.
Again, you appear to be confusing bit patterns on a disk with a C
stream. If there's a text stream, and it has more than one line, each
line must end with a newline.
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.
For good reason. Think about it.
What "operations" would you prohibit for each type of file? 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.
Unix scripts are executable text files ;-)
You may be thinking about certain loader formats which use only
printable characters.
--
Al Balmer
Balmer Consulting re************************@att.net
On 13 Nov 2003 13:33:51 GMT, Da*****@cern.ch (Dan Pop) wrote: In <lp********************************@4ax.com> Alan Balmer <al******@att.net> writes:
On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote:
Alan Balmer <al******@att.net> wrote:
What *you* don't "get" (or at least want to argue
about) is that any file may be opened in binary mode
That is true on many systems, but it is not guaranteed by the standard.
Nor is it prohibited by the standard.
Name me a system where it can't be done.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When you have to resort to Trollsdale favourite "argument", there *is*
something wrong with your position in the debate.
Dan
Incorrect premise - I did not "have to resort" to anything. Striking
the last line does not affect the truth of the posting.
OTOH, when you have to resort to this type of comment, I am forced to
conclude that you have no further useful input.
--
Al Balmer
Balmer Consulting re************************@att.net
Alan Balmer wrote:
On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote:
Alan Balmer <al******@att.net> wrote:
What *you* don't "get" (or at least want to argue
about) is that any file may be opened in binary mode
That is true on many systems, but it is not guaranteed by the standard.
Nor is it prohibited by the standard.
Name me a system where it can't be done.
Unix. fopen(".", "wb") will fail, even though the
file "." exists and even if it is writeable by the user
running the program.
-- Er*********@sun.com
On Thu, 13 Nov 2003 11:45:41 -0500, Eric Sosman <Er*********@sun.com>
wrote: Alan Balmer wrote:
On Wed, 12 Nov 2003 23:13:01 GMT, la************@eds.com wrote:
>Alan Balmer <al******@att.net> wrote:
>>
>> What *you* don't "get" (or at least want to argue
>> about) is that any file may be opened in binary mode
>
>That is true on many systems, but it is not guaranteed by the standard.
>
Nor is it prohibited by the standard.
Name me a system where it can't be done.
Unix. fopen(".", "wb") will fail, even though the
file "." exists and even if it is writeable by the user
running the program.
And fopen(".", "w") will succeed? I've never tried this (since "." is
the current directory in Unix, I've never had a need.) What's the
error code, if you know off-hand? Is this on all Unices? (The
questions are obviously off-topic for c.l.c, I'm just trying to
minimize my test time.)
--
Al Balmer
Balmer Consulting re************************@att.net
"Dan Pop" <Da*****@cern.ch> wrote in message
news:bp**********@sunnews.cern.ch... In <p7ysb.134611$275.397546@attbi_s53> "Glen Herrmannsfeldt"
<ga*@ugcs.caltech.edu> writes: "Dan Pop" <Da*****@cern.ch> wrote in message
news:bo**********@sunnews.cern.ch... In <3F***************@sun.com> Eric Sosman <Er*********@sun.com>
writes:
(snip)
> 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.
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.
That may be true, but I would be disappointed to find a system where
readinga C text file would not read text files commonly available on a system,
suchas produced by the systems normal text editor(s).
There is nothing preventing the system's normal text editor(s) from being
written in C ;-) It's even current practice, these days.
In that case, there shouldn't be any problems reading the files. In many
older systems, though, that wasn't true. Continuing my previous comments, I
don't believe that the TOPS-10 editors were written in C. It would be
unfortunate for a C implementation for TOPS-10 not to read the text files
written by other programs, even though it could follow a C standard exactly.
-- glen This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: TJ Walls |
last post by:
Hello All,
I am baffled ... I am trying to improve the speed of a program
that I have written that performs random access within a file. It
relies heavily on fseek and is very slow. To test, I...
|
by: Orion |
last post by:
Hey,
I was wondering if it was possible to determine if you hit 'EOF' using
fseek? I'm using fseek to traverse through the file from start to end
and capturing the data into a linked list...
|
by: cedarson |
last post by:
I am writing a program and have been instructeed to use the 'fseek',
'ftell', and 'stat' functions, however, after looking in the online
manual for each of these, I am still unsure on how to use...
|
by: Kenneth Brody |
last post by:
I recently ran into an "issue" related to text files and ftell/fseek,
and I'd like to know if it's a bug, or simply an annoying, but still
conforming, implementation.
The platform is Windows,...
|
by: Chen ShuSheng |
last post by:
HI,
I am now study a segment of codes:
------------------------
printf("%p\t",fp); /*add by me*/
fseek(fp, 0L, SEEK_END); /* go to end of file */
printf("%p\t",fp); ...
|
by: ericunfuk |
last post by:
A basic question:
When the documentation says "fseek() clears EOF indecator, does it
mean when you seek over EOF, EOF is no longer at the original position
and hence removed?Say, after I seek...
|
by: ericunfuk |
last post by:
I have posted a few other posts before this one today, I still can't
solve my problem, I think I need to elaborate my problem now.
I'm trying to send a file using UDP, below is a segment of my...
|
by: ericunfuk |
last post by:
If fseek() always clears EOF, is there a way for me to fread() from an
offset of a file and still be able to detect EOF?i.e. withouting using
fseek(). I also need to seek to an offset in the file...
|
by: thomas.mertes |
last post by:
Hello
Recently I discovered some problem. I have some C code
which determines how many bytes are available in a
file. Later I use this information to malloc a buffer of
the correct size before...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| |
