DEVCPP + rewind(stdin)

[Olaf \El Blanco\]

Where is exactly neccesary to put "rewind(stdin)"?
After a printf? Before a scanf?

I have a lot of problems with strings...
If somebody know any good document, please let me know where is...

Thank you.

 

[Flash Gordon]

Where is exactly neccesary to put "rewind(stdin)"?
After a printf? Before a scanf?

I've never needed to put it anywhere. I have, on the other hand, needed
to use fflush(stdout) before waiting for input.

I have a lot of problems with strings...
If somebody know any good document, please let me know where is...

The comp.lang.c FAQ http://c-faq.com/
K&R2 (see the FAQ for the full reference).

 

[Richard Heathfield]

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.

After a printf? Before a scanf?
Neither.

I have a lot of problems with strings...
If somebody know any good document, please let me know where is...

The best way to capture text input is either a single character at a time,
ONLY, or a line at a time, ONLY. One or the other, and which one you choose
depends on what you're doing.

I've put a little essay together on the subject of capturing text data a
line at a time, and you can find it at:

<http://www.cpax.org.uk/prg/writings/fgetdata.php>

 

[Keith Thompson]

Olaf "El Blanco" said:


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.

 

[Richard Tobin]

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

 

[Keith Thompson]

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.

 

[CBFalconer]

Olaf "El Blanco" said:


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

 

[Richard Tobin]

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/usr/source/s1/goto.c.html

-- Richard

 

[Keith Thompson]

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.

 

[Jordan Abel]

Olaf "El Blanco" said:


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.

 

[Jordan Abel]

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/usr/source/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?

 

[Richard Tobin]

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

 

[CBFalconer]

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

 

[Keith Thompson]

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.

 

[Richard Tobin]

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

 

[Kenneth Brody]

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:[email protected]>

 

[Richard Tobin]

<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

 

[Keith Thompson]

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.

 

[Jordan Abel]

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.

 

[Kenneth Brody]

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:[email protected]>