Puzzle!

W

Walter Roberson

The original was correct; the purpose of the code
is to consume '\n' characters.

Exactly -- and my posting specifically indicated that as the
intended behaviour.
 
T

Tak

Your response hints to me that you did not use fgets() or fgetc()
properly. The standard C library does not operate on "files", it
operates on "streams". It is entirely possible with C that one
run of a program will have a stream attached to a file and the
next run with the stream attached to a terminal, without any changes
in the code.

The key to using fgets() or fgetc() with the standard input stream
is to supply the FILE* parameter as the name stdin such as

if ( fgets(&mybuffer, sizeof mybuffer, stdin) != NULL ) { ... }
can you tell me how to deal with this "a+b problem" by /fgets/ in your
format?
P.S.
it's not homework.
the a+b problem:
Input:
The input will consist of a series of pairs of integers a and
b,separated by a space, one pair of integers per line.
Output:
For each pair of input integers a and b you should output the sum of a
and b in one line,and with one line of output for each line in input.
 
F

Flash Gordon

Tak wrote, On 05/06/07 11:05:
can you tell me how to deal with this "a+b problem" by /fgets/ in your
format?
P.S.
it's not homework.

You've still not attempted it though.
the a+b problem:
Input:
The input will consist of a series of pairs of integers a and
b,separated by a space, one pair of integers per line.
Output:
For each pair of input integers a and b you should output the sum of a
and b in one line,and with one line of output for each line in input.

Parse the lines with the parser of your choice, strtol for example, sum
the data and output it. Nothing difficult. If you want serious help make
a serious attempt yourself and post it.
 
A

Army1987

Walter Roberson said:
Exactly -- and my posting specifically indicated that as the
intended behaviour.
Since '\n' != EOF, couldn't you just write
while (getchar() == '\n)
continue;
?
 
W

Walter Roberson

Since '\n' != EOF, couldn't you just write
while (getchar() == '\n)
continue;

Good point, a seperate EOF test is not needed. But you do need to
capture the character that was read, as otherwise you end up discarding
the first non- EOF .

while ( (c = getchar()) == '\n' ) continue; /* consumes newlines */
 
B

BiGYaN

Some days ago, I written a mini program like this:
#include <stdio.h>

int main()
{
char c;
int n;

scanf("%d",&n);
c = getchar();

return 0;

}

I want to assign n and c specific values,for example,give n and c
values of 5 and 'x' in fact when I input 5 then "enter",the program
is finish.I know when I press "Enter", I assigned '\n' to variable c,
But how can I avoid this?



How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);
fflush(stdin);
c = getchar();

return 0;
}

fflush(stdin) just flushes out the "\n" from the buffer.
 
D

Default User

BiGYaN wrote:

fflush(stdin) just flushes out the "\n" from the buffer.

No, it doesn't. It is undefined behavior. Some implementations provide
extensions that do what you say, but many other don't.




Brian
 
K

Keith Thompson

Default User said:
No, it doesn't. It is undefined behavior. Some implementations provide
extensions that do what you say, but many other don't.

One system that I know of (Solaris) defines the behavior of
fflush(stdin) to discard any buffered input. I don't know of any
implementations on which it 'just flushes out the "\n"'. (Discarding
all input up to the next '\n' is easy enough to do without using
fflush().)

See questins 12.26a and 12.26b in the comp.lang.c FAQ,
<http://www.c-faq.com/>.
 
R

Richard Heathfield

BiGYaN said:

How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);

Calling a variadic function without a valid prototype in scope invokes
fflush(stdin);

stdin is undefined. If you define it appropriately by #include <stdio.h>
you then run into the problem that the behaviour of fflush is defined
only for streams open for output or update. stdin is neither.
c = getchar();

getchar returns int, not char.

To fit so many fundamental errors into such a short program, presumably
without trying to, is truly impressive.
 
D

Default User

Keith said:
One system that I know of (Solaris) defines the behavior of
fflush(stdin) to discard any buffered input. I don't know of any
implementations on which it 'just flushes out the "\n"'. (Discarding
all input up to the next '\n' is easy enough to do without using
fflush().)

I made the assumption, perhaps incorrectly, that the person explained
it badly. At that point, the only thing left in the buffer would be the
\n. I didn't take to mean that the person thought that fflush(stdin)
always would remove the \n and leave other characters. Frankly, I think
that reading of the post strains hard to make something of nothing.

See questins 12.26a and 12.26b in the comp.lang.c FAQ,
<http://www.c-faq.com/>.

Is this supposed to be for me? If so, why?



Brian
 
B

BiGYaN

One system that I know of (Solaris) defines the behavior of
fflush(stdin) to discard any buffered input. I don't know of any
implementations on which it 'just flushes out the "\n"'. (Discarding
all input up to the next '\n' is easy enough to do without using
fflush().)

See questins 12.26a and 12.26b in the comp.lang.c FAQ,
<http://www.c-faq.com/>.

--
Keith Thompson (The_Other_Keith) (e-mail address removed) <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"


@ Keith

Actually you interpreted it wrongly. What I wanted to say was that
fflush(stdin) will flush out the whole buffer. But in this case the
buffer had only a "\n". So I wrote "fflush(stdin) just flushes out the
"\n" from the buffer".

Hope you got my point now.

BTW, "Default User" has already clarified my point of view.
 
B

BiGYaN

BiGYaN said:





Calling a variadic function without a valid prototype in scope invokes


stdin is undefined. If you define it appropriately by #include <stdio.h>
you then run into the problem that the behaviour of fflush is defined
only for streams open for output or update. stdin is neither.


getchar returns int, not char.

To fit so many fundamental errors into such a short program, presumably
without trying to, is truly impressive.


I could never imagine writing a program in C without "#include
<stdio.h>". I just did not write it as I thought it was quite obvious
to add it at the start. But I'm sorry if it caused some inconvenience
to my not-so-learned friend.

As far as getchar() returning an int. Yes I know it does, but why
bother with that here. The original question asked for a solution and
I provided it. It will work fine in this case.
 
J

Joachim Schmitz

BiGYaN said:
@ Keith

Actually you interpreted it wrongly. What I wanted to say was that
fflush(stdin) will flush out the whole buffer. But in this case the
buffer had only a "\n". So I wrote "fflush(stdin) just flushes out the
"\n" from the buffer".
Still fflush() on an input stream invokes the deamons of undefined behavoir

Bye, Jojo
 
R

Richard Heathfield

BiGYaN said:

I could never imagine writing a program in C without "#include
<stdio.h>".

You managed it on this occasion.
I just did not write it as I thought it was quite obvious
to add it at the start.

It isn't obvious to the compiler.
But I'm sorry if it caused some inconvenience
to my not-so-learned friend.

I trust he'll forgive you (although your "not-so-learned" jab won't
please him very much).
As far as getchar() returning an int. Yes I know it does, but why
bother with that here.

You mean you *deliberately* introduced one of your (several) errors?
Why? If you found it way too much effort to get it right, why did you
go to even more trouble to get it wrong?

The correct type, int, actually takes *less* effort to type than the
incorrect type, char.
The original question asked for a solution and
I provided it.

You provided a broken "solution".
It will work fine in this case.

You know the sad thing? It probably will - you know those occasional
scandals where they cut open a child's toy, a teddy-bear or something,
and find that the manufacturer has stuffed it full of nails? That's
what your program reminds me of. Heck, who cares? Nobody will ever
notice, nobody will get hurt, it'll work fine...

If you are paid for writing C programs, sir, you are over-paid.
 
A

Army1987

BiGYaN said:
How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);
fflush(stdin);
c = getchar();

return 0;
}

fflush(stdin) just flushes out the "\n" from the buffer.

On your system, maybe, but the Standard says it is undefined
behaviour, so, on some other system it could do something
completely different (including teleporting your keyboard and your
hands into a water closet and, well, "flushing" them, or to be more
serious, making the program crash), and an implementation is not
even required to document what it does.
So, the fact that it does work on your system doesn't mean it will
also work on everybody else's.
 
P

pete

What I wanted to say was that
fflush(stdin) will flush out the whole buffer.

"Undefined behavior" is the best description
of what "fflush(stdin)" means.
fflush(stdin) can't be a reachable part of a "correct program".
fflush(stdin) doesn't belong on this newsgroup as a C code example.

N869
7.19.5.2 The fflush function
Synopsis
[#1]
#include <stdio.h>
int fflush(FILE *stream);
Description
[#2] If stream points to an output stream or an update
stream in which the most recent operation was not input, the
fflush function causes any unwritten data for that stream to
be delivered to the host environment to be written to the
file; otherwise, the behavior is undefined.
N869
4. Conformance
[#1] In this International Standard, ``shall'' is to be
interpreted as a requirement on an implementation or on a
program; conversely, ``shall not'' is to be interpreted as a
prohibition.
[#2] If a ``shall'' or ``shall not'' requirement that
appears outside of a constraint is violated, the behavior is
undefined. Undefined behavior is otherwise indicated in
this International Standard by the words ``undefined
behavior'' or by the omission of any explicit definition of
behavior. There is no difference in emphasis among these
three; they all describe ``behavior that is undefined''.
[#3] A program that is correct in all other aspects,
operating on correct data, containing unspecified behavior
shall be a correct program and act in accordance with
5.1.2.3.
 
H

Harald van =?UTF-8?B?RMSzaw==?=

CBFalconer said:
But it won't.

If the behaviour is undefined, any behaviour is allowed, including the
behaviour BiGYaN described. Saying that because the behaviour is undefined,
a particular behaviour will not happen, doesn't make sense. You can say
that the behaviour is non-portable, and perhaps (here, almost always) that
you should not rely on it, but not that it'll not happen.
 
M

Morris Dovey

Harald van Dijk wrote:

| If the behaviour is undefined, any behaviour is allowed, including
| the behaviour BiGYaN described. Saying that because the behaviour
| is undefined, a particular behaviour will not happen, doesn't make
| sense. You can say that the behaviour is non-portable, and perhaps
| (here, almost always) that you should not rely on it, but not that
| it'll not happen.

Huh?

Might I suggest that wise programmers avoid UB?
 
H

Harald van =?UTF-8?B?RMSzaw==?=

Morris said:
Harald van Dijk wrote:

| If the behaviour is undefined, any behaviour is allowed, including
| the behaviour BiGYaN described. Saying that because the behaviour
| is undefined, a particular behaviour will not happen, doesn't make
| sense. You can say that the behaviour is non-portable, and perhaps
| (here, almost always) that you should not rely on it, but not that
| it'll not happen.

Huh?

Might I suggest that wise programmers avoid UB?

Of course. I'm just saying that UB means "you can't rely on what will
happen" just as much as "you can't rely on what won't happen", which is
still a good reason to avoid it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top