DEVCPP + rewind(stdin)

Richard Heathfield <in*****@invalid.invalid> writes:

Olaf "El Blanco" said:
Where is exactly neccesary to put "rewind(stdin)"?

I've never done that in my life.

Think about what it would mean.

puts("Dear user: I know you have just spent the last twenty");
puts("minutes typing in all that stuff, and I thank you for");
puts("it - but now I'd like you to do it all again, EXACTLY");
puts("THE SAME as you did it last time.");

rewind(stdin);

I don't see that program lasting through to a second run.

[...]

If stdin is coming from an interactive device, rewind()ing it doesn't
make much sense. But if it's coming from, say, a disk file, then
rewind() *might* be a sensible thing to do.

However, the source from which stdin receives its input is generally
outside the control of the program. The rewind() function has its
uses, but if you're going to need to rewind() something, it should
probably be a named file (opened with fopen()), not stdin.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 24 '06 #4

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

However, the source from which stdin receives its input is generally
outside the control of the program. The rewind() function has its
uses, but if you're going to need to rewind() something, it should
probably be a named file (opened with fopen()), not stdin.

I find this unconvincing. The program has no control over whether
stdin is rewindable, but equally it has no control over whether stdin
is a file containing the right data, or even data in the right format.
It has no control over whether it's a file that it makes sense to open
in text mode. And on the other hand on many modern operating systems
it has no control over whether a named file is rewindable, especially
if the file name is not built in to the program. About the only way
to be sure a file is rewindable is for the program to create it
itself!

If you want to make your program robust against non-rewindable (or
non-fseekable) files, whether named or not, you need to use some
mechanism outside the C standard. For example in unix you might
test a file with stat() and copy it to a temporary file if necessary.

-- Richard

May 24 '06 #5

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
However, the source from which stdin receives its input is generally
outside the control of the program. The rewind() function has its
uses, but if you're going to need to rewind() something, it should
probably be a named file (opened with fopen()), not stdin.

I find this unconvincing. The program has no control over whether
stdin is rewindable, but equally it has no control over whether stdin
is a file containing the right data, or even data in the right format.
It has no control over whether it's a file that it makes sense to open
in text mode. And on the other hand on many modern operating systems
it has no control over whether a named file is rewindable, especially
if the file name is not built in to the program. About the only way
to be sure a file is rewindable is for the program to create it
itself!

If you want to make your program robust against non-rewindable (or
non-fseekable) files, whether named or not, you need to use some
mechanism outside the C standard. For example in unix you might
test a file with stat() and copy it to a temporary file if necessary.

I suppose it's a matter of style. There's nothing illegal about
rewind(stdin), but in practice it's more likely to fail than
rewind(some_file_I_opened_explicitly).

I would consider it poor style to attempt to call rewind(stdin). In
normal usage, my expectation is that a program will read its standard
input from beginning to end, and will not attempt to do any
re-positioning.

I was about to mention that you should, of course, always check
whether rewind() was successful -- but I see that you can't do that.
rewind(stream) is equivalent to (void)fseek(stream, 0L, SEEK_SET),
except that it clears the error indicator for the stream. In other
words, it deliberately ignores any errors.

Why was rewind() defined this way?

Based on that, I think I'd avoid using rewind() at all.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 24 '06 #6

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

In
normal usage, my expectation is that a program will read its standard
input from beginning to end, and will not attempt to do any
re-positioning.

I suppose expectations vary :-) I regard standard input as a natural
way to provide a program's primary input, regardless of how it is used
(I usually follow the unix convention of using stdin if no file name
is given on the command line).

Rewinding standard input in C has a long history. Here is an amusing
example predating the modern standard i/o library:

http://minnie.tuhs.org/UnixTree/V5/u...s1/goto.c.html

-- Richard

May 24 '06 #7

CBFalconer

Keith Thompson wrote:

Richard Heathfield <in*****@invalid.invalid> writes:
Olaf "El Blanco" said:
Where is exactly neccesary to put "rewind(stdin)"?

I've never done that in my life.

Think about what it would mean.

puts("Dear user: I know you have just spent the last twenty");
puts("minutes typing in all that stuff, and I thank you for");
puts("it - but now I'd like you to do it all again, EXACTLY");
puts("THE SAME as you did it last time.");

rewind(stdin);

I don't see that program lasting through to a second run.

[...]

If stdin is coming from an interactive device, rewind()ing it
doesn't make much sense. But if it's coming from, say, a disk
file, then rewind() *might* be a sensible thing to do.

However, the source from which stdin receives its input is
generally outside the control of the program. The rewind()
function has its uses, but if you're going to need to rewind()
something, it should probably be a named file (opened with
fopen()), not stdin.

And if the systems works the way I think it should work, then
rewind will fail when stdin is interactive, and work when stdin has
been redirected to a disk file.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

May 24 '06 #8

CBFalconer <cb********@yahoo.com> writes:

Keith Thompson wrote:

[...]

If stdin is coming from an interactive device, rewind()ing it
doesn't make much sense. But if it's coming from, say, a disk
file, then rewind() *might* be a sensible thing to do.

However, the source from which stdin receives its input is
generally outside the control of the program. The rewind()
function has its uses, but if you're going to need to rewind()
something, it should probably be a named file (opened with
fopen()), not stdin.

And if the systems works the way I think it should work, then
rewind will fail when stdin is interactive, and work when stdin has
been redirected to a disk file.

Except that rewind() has no mechanism for telling you that it failed.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 24 '06 #9

On 2006-05-24, Keith Thompson <ks***@mib.org> wrote:

Richard Heathfield <in*****@invalid.invalid> writes:
Olaf "El Blanco" said:
Where is exactly neccesary to put "rewind(stdin)"?

I've never done that in my life.

Think about what it would mean.

puts("Dear user: I know you have just spent the last twenty");
puts("minutes typing in all that stuff, and I thank you for");
puts("it - but now I'd like you to do it all again, EXACTLY");
puts("THE SAME as you did it last time.");

rewind(stdin);

I don't see that program lasting through to a second run.

[...]

If stdin is coming from an interactive device, rewind()ing it doesn't
make much sense. But if it's coming from, say, a disk file, then
rewind() *might* be a sensible thing to do.

However, the source from which stdin receives its input is generally
outside the control of the program. The rewind() function has its
uses, but if you're going to need to rewind() something, it should
probably be a named file (opened with fopen()), not stdin.

You could attempt to rewind (or seek) and complain loudly when it fails.

May 25 '06 #10

On 2006-05-24, Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
In
normal usage, my expectation is that a program will read its standard
input from beginning to end, and will not attempt to do any
re-positioning.

I suppose expectations vary :-) I regard standard input as a natural
way to provide a program's primary input, regardless of how it is used
(I usually follow the unix convention of using stdin if no file name
is given on the command line).

Rewinding standard input in C has a long history. Here is an amusing
example predating the modern standard i/o library:

http://minnie.tuhs.org/UnixTree/V5/u...s1/goto.c.html

It wouldn't work on a modern system since child processes don't share
the file position indicator.

right?

because that would be insane.

right?

May 25 '06 #11

In article <sl***********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:

It wouldn't work on a modern system since child processes don't share
the file position indicator.

right?

because that would be insane.

right?

Wrong! If they didn't share the file position, a shell script of
programs that read from standard input would all read from the start
of it.

-- Richard

May 25 '06 #12

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <sl***********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:
It wouldn't work on a modern system since child processes don't share
the file position indicator.

right?

because that would be insane.

right?

Wrong! If they didn't share the file position, a shell script of
programs that read from standard input would all read from the start
of it.

I don't know whether that's correct or not. I could probably figure
it out if I spent some time either thinking about it, looking it up,
or trying it.

But since standard C has no concept of child processes, the question
is off-topic here. Try comp.unix.programmer if you want to discuss it
further.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 25 '06 #13

CBFalconer

Keith Thompson wrote:

CBFalconer <cb********@yahoo.com> writes:
Keith Thompson wrote:

[...]
If stdin is coming from an interactive device, rewind()ing it
doesn't make much sense. But if it's coming from, say, a disk
file, then rewind() *might* be a sensible thing to do.

However, the source from which stdin receives its input is
generally outside the control of the program. The rewind()
function has its uses, but if you're going to need to rewind()
something, it should probably be a named file (opened with
fopen()), not stdin.

And if the systems works the way I think it should work, then
rewind will fail when stdin is interactive, and work when stdin
has been redirected to a disk file.

Except that rewind() has no mechanism for telling you that it failed.

Ulp. This may be an indication of how often I use rewind.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

May 25 '06 #14

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

But since standard C has no concept of child processes, the question
is off-topic here. Try comp.unix.programmer if you want to discuss it
further.

In that case your assertions about rewinding stdin are off topic,
since some of its effects (and has its advisability) depend on the
operating system.

But in any case, I've no intention of switching newsgroups whenever a
thread drifts a little.

-- Richard

May 25 '06 #15

Kenneth Brody

Richard Tobin wrote:

In article <sl***********************@random.yi.org>,
Jordan Abel <ra*******@gmail.com> wrote:
It wouldn't work on a modern system since child processes don't share
the file position indicator.

right?

because that would be insane.

right?

Wrong! If they didn't share the file position, a shell script of
programs that read from standard input would all read from the start
of it.

Wrong. It's right.

<OT>
When a child process is started, it may inherit the current file
positions from its parent. However, they aren't "shared" in the
sense of being related once the new process has been spawned.
That is, the child moving the file position has no effect on the
parent's or sibling's file position.
</OT>

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

May 25 '06 #16

In article <44***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.net> wrote:

<OT>
When a child process is started, it may inherit the current file
positions from its parent. However, they aren't "shared" in the
sense of being related once the new process has been spawned.
That is, the child moving the file position has no effect on the
parent's or sibling's file position.
</OT>
No, this is not true in unix. If it were, then how would the second
"head" command in the following shell command print the second line?

$ (head -1; head -1) <<EOF one
two
EOF

one
two

The first child must move the pointer for the parent shell process,
which is then inherited by the second child.

Of course, stdio buffering may obscure what is happening.

Try the following (obviously not pure standard C) program. Give it
at least three characters of input, say 123. The child will print
1 and 3 and the parent will print 2.

#include <stdio.h>
#include <unistd.h>

int main(void)
{
char buf[1];

if(fork() == 0)
{
read(0, buf, 1);
printf("child read %c\n", buf[0]);
sleep(2);
read(0, buf, 1);
printf("child read %c\n", buf[0]);
}
else
{
sleep(1);
read(0, buf, 1);
printf("parent read %c\n", buf[0]);
}

return 0;
}

-- Richard

May 25 '06 #17

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
But since standard C has no concept of child processes, the question
is off-topic here. Try comp.unix.programmer if you want to discuss it
further.

In that case your assertions about rewinding stdin are off topic,
since some of its effects (and has its advisability) depend on the
operating system.

stdin and rewind() are standard. General discussions of how they
should be used seem to me to be sufficiently topical.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 25 '06 #18

On 2006-05-25, Keith Thompson <ks***@mib.org> wrote:

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
But since standard C has no concept of child processes, the question
is off-topic here. Try comp.unix.programmer if you want to discuss it
further.

In that case your assertions about rewinding stdin are off topic,
since some of its effects (and has its advisability) depend on the
operating system.

stdin and rewind() are standard. General discussions of how they
should be used seem to me to be sufficiently topical.

Given the complete and total lack of error reporting, I'd go so far as
to say "never". They can't do anything that fseek can't.

May 25 '06 #19

Kenneth Brody

Jordan Abel wrote:

On 2006-05-25, Keith Thompson <ks***@mib.org> wrote:

[...]

stdin and rewind() are standard. General discussions of how they
should be used seem to me to be sufficiently topical.

Given the complete and total lack of error reporting, I'd go so far as
to say "never". They can't do anything that fseek can't.

On my system, rewind() says it also clears any error status, which is
something fseek() doesn't do.

I don't know if that's standard or not, however.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

May 26 '06 #20

Kenneth Brody <ke******@spamcop.net> writes:

Jordan Abel wrote:

On 2006-05-25, Keith Thompson <ks***@mib.org> wrote:

[...]
> stdin and rewind() are standard. General discussions of how they
> should be used seem to me to be sufficiently topical.

Given the complete and total lack of error reporting, I'd go so far as
to say "never". They can't do anything that fseek can't.

On my system, rewind() says it also clears any error status, which is
something fseek() doesn't do.

I don't know if that's standard or not, however.

Yes, it is.

C99 7.19.9.5:

The rewind function sets the file position indicator for the
stream pointed to by stream to the beginning of the file. It is
equivalent to

(void)fseek(stream, 0L, SEEK_SET)

except that the error indicator for the stream is also cleared.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 26 '06 #21

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

The rewind function sets the file position indicator for the
stream pointed to by stream to the beginning of the file. It is
equivalent to

(void)fseek(stream, 0L, SEEK_SET)

except that the error indicator for the stream is also cleared.

Is this a mistake? Perhaps the intention was that it should clear the
error indication *before* the fseek? Or that a successful call should
clear it (as with fseek and the end-of-file indication)? That would
make a lot more sense.

-- Richard

May 26 '06 #22

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
The rewind function sets the file position indicator for the
stream pointed to by stream to the beginning of the file. It is
equivalent to

(void)fseek(stream, 0L, SEEK_SET)

except that the error indicator for the stream is also cleared.

Is this a mistake? Perhaps the intention was that it should clear the
error indication *before* the fseek? Or that a successful call should
clear it (as with fseek and the end-of-file indication)? That would
make a lot more sense.

Yes, it would, but I think it was deliberate.

fseek() returns an int value that indicates whether it succeeded.
rewind() returns void. That can't have been accidental. The wording
is identical in the C90 standard. (Prior to that, rewind() would have
implicitly returned int; I don't know whether the result was
meaningful in pre-ANSI implementations.)

The Rationale says:

Resetting the end-of-file and error indicators was added to the
specification of rewind to make the specification more logically
consistent.

Perhaps this is a question for comp.std.c.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

May 26 '06 #23

Walter Roberson

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

fseek() returns an int value that indicates whether it succeeded.
rewind() returns void. That can't have been accidental. The wording
is identical in the C90 standard. (Prior to that, rewind() would have
implicitly returned int; I don't know whether the result was
meaningful in pre-ANSI implementations.)

K&R2's description of rewind is:

void rewind(FILE *stream)
rewind(fp) is equivalent to fseek(fp,0L,SEEK_SET); clearerr(fp) .

That's pretty clear that the error is cleared even if the fseek() fails.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

May 26 '06 #24