Puzzle!

[Tak]

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?

[Walter Roberson]

In article <f4**********@tdi.cu.mi.it>, Army1987 <pl********@for.itwrote:

>>>Walter Roberson wrote:

>>while ( (c = getchar()) != EOF && c == '\n' )
{ /* empty loop body */ }

>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 */
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

[BiGYaN]

On Jun 1, 10:15 pm, Tak <[e-mail]:

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.

[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

[Keith Thompson]

"Default User" <de***********@yahoo.comwrites:

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.

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) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

BiGYaN said:

<snip>

How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);

Calling a variadic function without a valid prototype in scope invokes
undefined behaviour. To fix this, #include <stdio.hYou also fail to
check that your request for an integer value succeeded.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Default User]

Keith Thompson wrote:

"Default User" <de***********@yahoo.comwrites:

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.

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

[CBFalconer]

BiGYaN wrote:

>

.... snip ...

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

No it doesn't. It incites UB. fflush only works on output files.
Try:

int flushln(FILE *f) {
int ch;

while (('\n' != (ch = getc(f))) && (EOF != ch)) continue;
return ch;
}

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[BiGYaN]

On Jun 10, 1:38 am, Keith Thompson <[e-mail]:

"Default User" <[e-mail]:

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.

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

[BiGYaN]

On Jun 10, 2:55 am, Richard Heathfield <[e-mail]:

BiGYaN said:

<snip>

How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);

Calling a variadic function without a valid prototype in scope invokes
undefined behaviour. To fix this, #include <stdio.hYou also fail to
check that your request for an integer value succeeded.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999http://www.cpax.org.uk
email: rjh at the above domain, - www.

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.

[Joachim Schmitz]

"BiGYaN" <bi***********@gmail.comschrieb im Newsbeitrag
news:11**********************@n15g2000prd.googlegr oups.com...

On Jun 10, 1:38 am, Keith Thompson <[e-mail]:

>"Default User" <[e-mail]:

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.

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

Still fflush() on an input stream invokes the deamons of undefined behavoir

Bye, Jojo

[Richard Heathfield]

BiGYaN said:

<snip>

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Army1987]

"BiGYaN" <bi***********@gmail.comha scritto nel messaggio
news:11*********************@r19g2000prf.googlegro ups.com...

On Jun 1, 10:15 pm, Tak <[e-mail]:

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

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.

[pete]

BiGYaN wrote:

>
On Jun 10, 1:38 am, Keith Thompson <[e-mail]:

"Default User" <[e-mail]:

BiGYaN wrote:
>fflush(stdin) just flushes out the "\n" from the buffer.

No, it doesn't. It is undefined behavior.

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.

--
pete

[CBFalconer]

BiGYaN wrote:

>

.... snip ...

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

Because without the int declaration you can't detect EOF.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

BiGYaN wrote:

>

.... snip ...

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

But it won't. It will just cause undefined behaviour to occur. I
gave you a replacement method that will always work.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

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

CBFalconer wrote:

BiGYaN wrote:

>>

... snip ...

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

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.

[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?

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/

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

Morris Dovey wrote:

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.

[Keith Thompson]

BiGYaN <bi***********@gmail.comwrites:

On Jun 10, 1:38 am, Keith Thompson <[e-mail]:

>"Default User" <[e-mail]:

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.

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] <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"

Please trim quoted material when you post a followup. I particular,
don't quote singatures unless you're actually commenting on them.

@ Keith

(A very minor point; there's no "@" in my name.)

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.

The fact that fflush(stdin) invokes undefined behavior has been
pounded to death, so I won't mention it again. (Oops, I just did!)
But on a system that does define the behavior, namely Solaris, the man
page says:

Flushing an input stream discards any buffered input and adjusts
the file pointer such that the next input operation accesses the
byte after the last one read.

For input from a keyboard, that means (I think) that it discards
anything in the typeahead buffer, i.e., any characters that the user
has typed that have not yet been read by input operations. You *don't
know* that the input buffer contains only a '\n' character; it could
contain anything.

fflush(stdin) is undefined; when it is defined, it doesn't necessarily
do what you think it does.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

BiGYaN <bi***********@gmail.comwrites:

On Jun 10, 2:55 am, Richard Heathfield <[e-mail]:

>BiGYaN said:

<snip>

How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);

[snip]

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

You say could never imagine it, but how are we supposed to know that?
Plenty of programmers *don't* know that the "#include <stdio.h>" is
required, and omit it in real programs. You may be a good enough
programmer that you never make that mistake yourself, but the only way
we can know that is if you demonstrate it. In this case, you
demonstrated the opposite.

You need to be just as careful with code you post here as with code
you write in the real world. The readers of this newsgroup tend to be
far more strict that most compilers, perhaps more so than any of them.

Referring to Richard Heathfield as "not-so-learned" is an error (one
that he's already taken with his usual good humor). Stick around here
for a while, and you'll see that it's very far from the truth.

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.

"It will work fine in this case" is perhaps the greatest source of
errors, some of which may have drastic consequences. getchar()
returns an int. There is *never* a good reason to assign its result
to a char.

Code you post to comp.lang.c is unlikely to be cause any problems in
the real world; nobody is going to take a code snippet posted here and
use it to run a nuclear reactor. The worst consequence, as I hope
you're seeing now, is a bit of personal embarrassment. But this is an
opportunity to develop good habits that will serve you (and your
users) very well when you write code for the real world. Don't expect
us to ignore errors because they don't matter here; this is a learning
forum, and errors matter very much.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

<snip>

Referring to Richard Heathfield as "not-so-learned" is an error

Oh, did he mean me? I thought he was referring to the OP. Well, if he
meant me, I look forward to becoming more learnederer.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Morris Dovey]

Keith Thompson wrote:
| BiGYaN <bi***********@gmail.comwrites:

<code-specific snipage>

| You need to be just as careful with code you post here as with code
| you write in the real world. The readers of this newsgroup tend to
| be far more strict that most compilers, perhaps more so than any of
| them.

Although it's sometimes a PIA and sometimes produces a certain amount
of chagrin, it's exactly this that makes the newsgroup a valuable
resource. Nowhere else will your work ever receive a higher-quality
peer review.

| Referring to Richard Heathfield as "not-so-learned" is an error (one
| that he's already taken with his usual good humor). Stick around
| here for a while, and you'll see that it's very far from the truth.

Seconded. I'd suggest being /very/ wary of aspersing anyone here until
you absolutely know you're on solid ground. FWIW, if I ever needed to
assemble a software "dream team" for a project on which many lives
depended, nearly all of the candidates would be drawn from my list of
c.l.c regulars.

|| 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.
|
| "It will work fine in this case" is perhaps the greatest source of
| errors, some of which may have drastic consequences. getchar()
| returns an int. There is *never* a good reason to assign its result
| to a char.

"Wisdom" is a word that would seem to have fallen from common usage.
One of its more important nuances involves knowledge of and
consideration for consequence based on experience. I'd encourage you
to accept the gift whenever it's offered.

| Code you post to comp.lang.c is unlikely to be cause any problems in
| the real world; nobody is going to take a code snippet posted here
| and use it to run a nuclear reactor. The worst consequence, as I
| hope you're seeing now, is a bit of personal embarrassment. But
| this is an opportunity to develop good habits that will serve you
| (and your users) very well when you write code for the real world.
| Don't expect us to ignore errors because they don't matter here;
| this is a learning forum, and errors matter very much.

Keith may be a bit optimistic here. More than just a little of the
code posted here has gone into real-world applications - although
probably not without local peer review. The rest is 24-carat truth.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/

[Joachim Schmitz]

"CBFalconer" <cb********@yahoo.comschrieb im Newsbeitrag
news:46**************@yahoo.com...

BiGYaN wrote:

>>

... snip ...

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

Because without the int declaration you can't detect EOF.

Well, to be fair: in his small sample program he wasn't looking for EOF...

Bye, Jojo

[Richard Heathfield]

Joachim Schmitz said:

"CBFalconer" <cb********@yahoo.comschrieb im Newsbeitrag
news:46**************@yahoo.com...

>>
Because without the int declaration you can't detect EOF.

Well, to be fair: in his small sample program he wasn't looking for
EOF...

To be even fairer, he *should* have been looking for EOF.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Keith Thompson said:

<snip>

>Referring to Richard Heathfield as "not-so-learned" is an error

Oh, did he mean me? I thought he was referring to the OP. Well, if he
meant me, I look forward to becoming more learnederer.

Looking back at the previous article, I'm not sure who he was
referring to. I read it as referring to you, but I could easily have
been mistaken.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[J. J. Farrell]

On Jun 10, 12:44 am, BiGYaN <[e-mail]:

On Jun 10, 2:55 am, Richard Heathfield <[e-mail]:

BiGYaN said:

<snip>

How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);

Calling a variadic function without a valid prototype in scope invokes
undefined behaviour. To fix this, #include <stdio.hYou also fail to
check that your request for an integer value succeeded.

...

c = getchar();

getchar returns int, not char.

...

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

How are we supposed to know the limitations of your imagination? This
particular limitation implies a lack of wide experience.

...

As far as getchar() returning an int. Yes I know it does, but why
bother with that here.

Because it would require less typing and effort than the wrong way you
chose to do it? Because it would avoid bugs and wasted effort further
down the line when someone expands this sketch into a real program?

I'm intrigued to know why you would waste the time and effort to work
out whether or not there was any actual need to use an int in this
case, then choose to go to the extra effort of more typing to put char
instead of int. You'd have saved yourself thinking time and typing
time by just using the correct type in the first place. Doesn't seem a
very efficient way to work.

[KIRAN]

On Jun 1, 10:15 pm, Tak <[e-mail]:

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?

#include<stdio.h>
int main()
{
char c;
int n;

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

return 0;

}

[Keith Thompson]

KIRAN <ki*****@gmail.comwrites:
[snip]

#include<stdio.h>
int main()
{
char c;
int n;

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

return 0;

}

No, no, no, no, and did I mention, NO!

fflush(stdin) invokes undefined behavior. Read the lengthy
explanations of that fact in this very thread. And read questions
12.26a and 12.26b in the comp.lang.c FAQ, <http://www.c-faq.com/>.

And getchar() returns an int, not a char; that's also been discussed
at length in this thread.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Barry Schwarz]

On Sun, 10 Jun 2007 21:00:44 -0700, KIRAN <ki*****@gmail.comwrote:

>On Jun 1, 10:15 pm, Tak <[e-mail]:

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

#include<stdio.h>
int main()
{
char c;
int n;

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

Have you made any effort to follow the thread? Do you know that
passing an input stream to fflush invokes undefined behavior?

c = getchar();

return 0;

}

Remove del for email

[Urs Beeli]

On Sun, 10 Jun 2007 12:10:08 -0500 Morris Dovey wrote:

Keith Thompson wrote:
| BiGYaN <bi***********@gmail.comwrites:

<code-specific snipage>

| You need to be just as careful with code you post here as with code
| you write in the real world. The readers of this newsgroup tend to
| be far more strict that most compilers, perhaps more so than any of
| them.

Although it's sometimes a PIA and sometimes produces a certain amount
of chagrin, it's exactly this that makes the newsgroup a valuable
resource. Nowhere else will your work ever receive a higher-quality
peer review.

I guess much of the bickering we get on this newsgroup comes from the
different mindset its readers have. There are those that...

| But this is an opportunity to develop good habits that will serve you
| (and your users) very well when you write code for the real world. Don't
| expect us to ignore errors because they don't matter here; this is a
| learning forum, and errors matter very much.

... appreciate this strictness and perpetual advising to use these good
habits in all code, even small samples posted to c.l.c. I count myself as
one of those, as I have learnt a lot from the nitpicking regulars advocating
safe coding in all cicumstances.

Then, there are those who are stuck on a problem (be it homework, first
steps in C, work related) who want a quick fix and are happy if it gets them
one step further, not caring about portability, undefined behaviour. To
those, being constantly admonished that their "working program" is not of
satisfactory quality to the regulars here, will most likely seem to be
annoying or even appear arrogant.

I remember may first steps in programming C, I did a lot of trial and error,
I picked up bits and pieces here and there. I can't promise that I never
fflushed(stdin), though I never used scanf (because I couldn't get it to
work, not because I found it unsafe). At the time, a quick fix would have
satisfied me.

It took me years to learn from my mistakes, to hear about and read K&R2, to
find this group and get to know about the standard. Amazingly, some of this
even happened after I took programming from a hobby to a job.

I have profited incredibly from lurking in c.l.c and becoming a nitpicker in
my own code has made it more portable, safer and easier to maintain.
I think what the regulars here sometimes forget (and I can understand why
they do) is that there are people that do not yet understand why being
strict in coding is so important and that making them understand this takes
as much patience (maybe even more) than teaching them C.

And I would hope that those that do not yet see eye to eye with the regulars
try to learn this lesson without being offended, if their mistakes are
pointed out with little empathy :)

Cheers
/urs

--
"Change is inevitable, except from a vending machine."
-- Urs Beeli, <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch>

[Richard Heathfield]

Urs Beeli said:

<snip>

It took me years to learn from my mistakes, to hear about and read
K&R2, to find this group and get to know about the standard.
Amazingly, some of this even happened after I took programming from a
hobby to a job.

That's not so amazing as it should be, alas.

>
I have profited incredibly from lurking in c.l.c and becoming a
nitpicker in my own code has made it more portable, safer and easier
to maintain.

I'm delighted to hear it. Do you want a job in clc's PR department? :-)

I think what the regulars here sometimes forget (and I can understand
why they do) is that there are people that do not yet understand why
being strict in coding is so important and that making them understand
this takes as much patience (maybe even more) than teaching them C.

You're right, and it does take a lot of patience. Nevertheless, it also
takes patience on the part of those who are seeking help. I remember
getting a similarly rough ride from the regulars when I started using
clc, but it was so clear to me that they knew what they were talking
about that I put up with it, despite occasional rebuffs that I still
remember even now. For example, I once had a sig block in which I added
a new line for each new thing I'd learned in clc - until a regular
contributor pointed out that it was likely to become an extremely long
list! :-) (The worrying thing is that he wasn't just being unkind - he
was also absolutely right!)

And I would hope that those that do not yet see eye to eye with the
regulars try to learn this lesson without being offended, if their
mistakes are pointed out with little empathy :)

Those who demonstrate that they really are trying to learn will normally
get pretty patient treatment here. But those who are looking for a
quick fix, a homework cheat or whatever, will find that the regulars
tend to undergo an empathectomy before responding.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ben Bacarisse]

KIRAN <ki*****@gmail.comwrites:

On Jun 1, 10:15 pm, Tak <[e-mail]:

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

<another version with undefined behaviour snipped>

Just because it has not (I think) been posted yet, I will say that it
is *possible*, that what the OP wanted was something like:

if (scanf("%d %c", &n, &c) == 2) {
/* do something with the input... *.
...
}

--
Ben.

[BiGYaN]

On Jun 10, 8:46 pm, Keith Thompson <[e-mail]:

BiGYaN <[e-mail]:

On Jun 10, 1:38 am, Keith Thompson <[e-mail]:

"Default User" <[e-mail]:
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.

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] <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"

Please trim quoted material when you post a followup. I particular,
don't quote singatures unless you're actually commenting on them.

@ Keith

(A very minor point; there's no "@" in my name.)

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.

The fact that fflush(stdin) invokes undefined behavior has been
pounded to death, so I won't mention it again. (Oops, I just did!)
But on a system that does define the behavior, namely Solaris, the man
page says:

Flushing an input stream discards any buffered input and adjusts
the file pointer such that the next input operation accesses the
byte after the last one read.

For input from a keyboard, that means (I think) that it discards
anything in the typeahead buffer, i.e., any characters that the user
has typed that have not yet been read by input operations. You *don't
know* that the input buffer contains only a '\n' character; it could
contain anything.

fflush(stdin) is undefined; when it is defined, it doesn't necessarily
do what you think it does.

--
Keith Thompson (The_Other_Keith) [e-mail] <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"

I really did not know about this undefined behavior of "fflush(stdin)"
in C. Actually I had the same problem like this once and I solved it
using another dummy getchar() to consume the "\n". But then a friend
of mine showed me this function and I've been using it ever since. As
far I know it works in Windows, Solaris and Linux. I have no idea what
it does in other OSs as I simply don't have access to them.

As far as that getchar() and stdio.h is concerned, I just copy pasted
the code that was present in the starting post, so I didn't bother to
modify it. As far as I understood the problem the person had a problem
with that "\n" only. So I modified the code as little as possible. It
was just a quick and simple solution.
BTW, I am quite sure RH will surely quote this "quick and simple
solution". But let's wait for that.

As for that "@" it was supposed to mean "at". I see it being used
often in chat rooms to aim messages at a particular person and not the
group in general. So I just follwed it, not quite realizing that it
would be an alien protocol here.

As far that "not-so-learned" jab goes .... it's good to see multiple
interpretations of it. I never quite thought it could be interpreted
from 2 different angles. :)
I guess it is better to keep it open to interpretations, adding some
more fun to it.

[BiGYaN]

On Jun 10, 8:57 pm, Keith Thompson <[e-mail]:

BiGYaN <[e-mail]:

On Jun 10, 2:55 am, Richard Heathfield <[e-mail]:

BiGYaN said:

<snip>

How about this one :

int main()
{
char c;
int n;

scanf("%d",&n);

[snip]

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.

You say could never imagine it, but how are we supposed to know that?
Plenty of programmers *don't* know that the "#include <stdio.h>" is
required, and omit it in real programs.

Ok, I didn't know that plenty of programmers don't know this. Actually
it was stressed so much in my C courses, that I really thought it was
quite obvious.

.... You may be a good enough
programmer that you never make that mistake yourself, but the only way
we can know that is if you demonstrate it. In this case, you
demonstrated the opposite.

I am just a Post Graduate CS student. I don't claim to be "good
enough". But I do agree that I was a bit callous in this case. I'll
surely keep your good advice in mind the next time I write a code.

You need to be just as careful with code you post here as with code
you write in the real world. The readers of this newsgroup tend to be
far more strict that most compilers, perhaps more so than any of them.

Yup I agree on the first point. The 2nd point is being proved in this
thread only. But I'll surely try to follow your advice.

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.

"It will work fine in this case" is perhaps the greatest source of
errors, some of which may have drastic consequences. getchar()
returns an int. There is *never* a good reason to assign its result
to a char.

You might be right. Actually before taking that SW Engineering paper
on last year, I really never thought much of standards and
portability. Whatever compiled in both Windows and Linux was OK for
me. But I do have the realization now.

Code you post to comp.lang.c is unlikely to be cause any problems in
the real world; nobody is going to take a code snippet posted here and
use it to run a nuclear reactor. The worst consequence, as I hope
you're seeing now, is a bit of personal embarrassment. But this is an
opportunity to develop good habits that will serve you (and your
users) very well when you write code for the real world. Don't expect
us to ignore errors because they don't matter here; this is a learning
forum, and errors matter very much.

Well I am a student of CS. I am here to learn and maybe help others in
the process too. So I really don't mind. But I must confess, I never
thought that this small snippet of code could result in so many posts.

[Ian Collins]

BiGYaN wrote:

On Jun 10, 8:46 pm, Keith Thompson <[e-mail]:

>Please trim quoted material when you post a followup. I particular,
don't quote singatures unless you're actually commenting on them.

--
Keith Thompson (The_Other_Keith) [e-mail] <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"

Did you read what Keith wrote about trimming?

--
Ian Collins.

[Richard Heathfield]

BiGYaN said:

<snip>

BTW, I am quite sure RH will surely quote this "quick and simple
solution".

How can I? I didn't /see/ a solution. All I saw was a series of
problems.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Flash Gordon]

BiGYaN wrote, On 11/06/07 20:37:

<snip>

I really did not know about this undefined behavior of "fflush(stdin)"
in C. Actually I had the same problem like this once and I solved it
using another dummy getchar() to consume the "\n". But then a friend
of mine showed me this function and I've been using it ever since. As
far I know it works in Windows, Solaris and Linux. I have no idea what
it does in other OSs as I simply don't have access to them.

You can't rely on the behaviour staying the same even on those systems
where it is documented. On the version of Linux I am running here, for
example, the documentation lists the stream not being open for output
(which stdin is not normally) as an error condition. It could just as
well have made the change without documenting the behaviour.

<snip>

As far as that getchar() and stdio.h is concerned, I just copy pasted
the code that was present in the starting post, so I didn't bother to
modify it. As far as I understood the problem the person had a problem
with that "\n" only. So I modified the code as little as possible. It
was just a quick and simple solution.
BTW, I am quite sure RH will surely quote this "quick and simple
solution". But let's wait for that.

It is only a quick and simple solution if it is correct, anything that
is not correct does not IMHO count as a solution.

As for that "@" it was supposed to mean "at". I see it being used
often in chat rooms to aim messages at a particular person and not the
group in general. So I just follwed it, not quite realizing that it
would be an alien protocol here.

<snip>

Now you know that we don't do chatroom-speak here.
--
Flash Gordon

[Keith Thompson]

BiGYaN <bi***********@gmail.comwrites:

On Jun 10, 8:46 pm, Keith Thompson <[e-mail]:

>BiGYaN <[e-mail]:

On Jun 10, 1:38 am, Keith Thompson <[e-mail]:

[...]

>Please trim quoted material when you post a followup. I particular,
don't quote singatures unless you're actually commenting on them.

Please read the above again; you're still failing to trim quoted
material.

[...]

I really did not know about this undefined behavior of "fflush(stdin)"
in C.

The comp.lang.c FAQ is at <http://www.c-faq.com/>. It's an excellent
source of information, and one that you should check before posting
here.

[...]

As far as that getchar() and stdio.h is concerned, I just copy pasted
the code that was present in the starting post, so I didn't bother to
modify it. As far as I understood the problem the person had a problem
with that "\n" only. So I modified the code as little as possible. It
was just a quick and simple solution.

Ok, that's a fair point. I've sometimes posted modified code that
corrects one error without noticing that there was another error.

But I don't then defend the error, as you did.

As for that "@" it was supposed to mean "at". I see it being used
often in chat rooms to aim messages at a particular person and not the
group in general. So I just follwed it, not quite realizing that it
would be an alien protocol here.

I've never seen that convention, but then I don't hang out in chat
rooms.

As far that "not-so-learned" jab goes .... it's good to see multiple
interpretations of it. I never quite thought it could be interpreted
from 2 different angles. :)
I guess it is better to keep it open to interpretations, adding some
more fun to it.

It came across as a deliberate insult directed at an individual. Even
if you didn't mean it that way, I see nothing "fun" about that. (Yes,
I did just post a long message advising someone else to grow a thicker
skin. I'm not always entirely consistent.)

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

BiGYaN wrote:

>

.... snip ...

>
Well I am a student of CS. I am here to learn and maybe help
others in the process too. So I really don't mind. But I must
confess, I never thought that this small snippet of code could
result in so many posts.

We can pick interminable holes in almost anything.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

KIRAN wrote:

Tak <[e-mail]:

.... snip ...

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

#include<stdio.h>
int main() {
char c;
int n;

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

You haven't even been following this thread. fflush(stdin) cause
undefined behaviour.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Joachim Schmitz]

"Keith Thompson" <ks***@mib.orgschrieb im Newsbeitrag
news:ln************@nuthaus.mib.org...

BiGYaN <bi***********@gmail.comwrites:

>On Jun 10, 8:46 pm, Keith Thompson <[e-mail]:

[...]

>As for that "@" it was supposed to mean "at". I see it being used
often in chat rooms to aim messages at a particular person and not the
group in general. So I just follwed it, not quite realizing that it
would be an alien protocol here.

I've never seen that convention, but then I don't hang out in chat
rooms.

So you've learned something new today. It is common not only in chat rooms,
but also in forums (or whatever the plural of forum might be), which is
quite a similar concept to news.

>As far that "not-so-learned" jab goes .... it's good to see multiple
interpretations of it. I never quite thought it could be interpreted
from 2 different angles. :)
I guess it is better to keep it open to interpretations, adding some
more fun to it.

It came across as a deliberate insult directed at an individual. Even

I know the feeling ;-), although I didn't find this one insulting

if you didn't mean it that way, I see nothing "fun" about that. (Yes,
I did just post a long message advising someone else to grow a thicker
skin. I'm not always entirely consistent.)

Gotcha! 8-))

Bye, Jojo

[Richard Heathfield]

Joachim Schmitz said:

"Keith Thompson" <ks***@mib.orgschrieb...

>BiGYaN <bi***********@gmail.comwrites:

[...]

>>As for that "@" it was supposed to mean "at". I see it being used
often in chat rooms to aim messages at a particular person and not
the group in general. So I just follwed it, not quite realizing that
it would be an alien protocol here.

I've never seen that convention, but then I don't hang out in chat
rooms.

So you've learned something new today. It is common not only in chat
rooms,

I don't think I've ever seen it in IRC...

but also in forums (or whatever the plural of forum might be),

"fora", although Chambers also lists "forums".

which is quite a similar concept to news.

Except that Web fora tend to be linear, which is a real nuisance.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Urs Beeli]

On Mon, 11 Jun 2007 11:36:07 +0000 Richard Heathfield wrote:

Urs Beeli said:

It took me years to learn from my mistakes, to hear about and read
K&R2, to find this group and get to know about the standard.
Amazingly, some of this even happened after I took programming from a
hobby to a job.

That's not so amazing as it should be, alas.

True enough :)

I have profited incredibly from lurking in c.l.c and becoming a
nitpicker in my own code has made it more portable, safer and easier
to maintain.

I'm delighted to hear it. Do you want a job in clc's PR department? :-)

It depends on how well it pays :-)

And I would hope that those that do not yet see eye to eye with the
regulars try to learn this lesson without being offended, if their
mistakes are pointed out with little empathy :)

Those who demonstrate that they really are trying to learn will normally
get pretty patient treatment here.

True.

But those who are looking for a quick fix, a homework cheat or whatever,
will find that the regulars tend to undergo an empathectomy before
responding.

Also true. And I understand that this is based on a long an exhaustive
stream of annoying and inconsiderate posters. However, I am sure that even
among those that are looking for a quick fix, a homework cheat or whatever,
there are those who would show more understanding if the empathectomy were
slightly incomplete :) Of course, the majority would probably stay the way
they are, taxing this groups patience :-/

Cheers
/urs

--
"Change is inevitable, except from a vending machine."
-- Urs Beeli, <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.ch>

[Keith Thompson]

Urs Beeli <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.chwrites:

On Mon, 11 Jun 2007 11:36:07 +0000 Richard Heathfield wrote:

> Urs Beeli said:

[...]

I have profited incredibly from lurking in c.l.c and becoming a
nitpicker in my own code has made it more portable, safer and easier
to maintain.

I'm delighted to hear it. Do you want a job in clc's PR department? :-)

It depends on how well it pays :-)

That would be "no", then. 8-)}

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[BiGYaN]

On Jun 12, 1:27 am, Richard Heathfield <[e-mail]:

BiGYaN said:

<snip>

BTW, I am quite sure RH will surely quote this "quick and simple
solution".

How can I? I didn't /see/ a solution. All I saw was a series of
problems.

;) But you quoted it anyway !! ;)

[BiGYaN]

On Jun 12, 2:44 am, CBFalconer <[e-mail]:

BiGYaN wrote:

... snip ...

Well I am a student of CS. I am here to learn and maybe help
others in the process too. So I really don't mind. But I must
confess, I never thought that this small snippet of code could
result in so many posts.

We can pick interminable holes in almost anything.

That's what I observe.

[BiGYaN]

On Jun 12, 2:20 am, Keith Thompson <[e-mail]:

BiGYaN <[e-mail]:

On Jun 10, 8:46 pm, Keith Thompson <[e-mail]:

BiGYaN <[e-mail]:
On Jun 10, 1:38 am, Keith Thompson <[e-mail]:

[...]

Please trim quoted material when you post a followup. I particular,
don't quote singatures unless you're actually commenting on them.

Please read the above again; you're still failing to trim quoted
material.

[...]

I really did not know about this undefined behavior of "fflush(stdin)"
in C.

The comp.lang.c FAQ is at <http://www.c-faq.com/>. It's an excellent
source of information, and one that you should check before posting
here.

[...]

As far as that getchar() and stdio.h is concerned, I just copy pasted
the code that was present in the starting post, so I didn't bother to
modify it. As far as I understood the problem the person had a problem
with that "\n" only. So I modified the code as little as possible. It
was just a quick and simple solution.

Ok, that's a fair point. I've sometimes posted modified code that
corrects one error without noticing that there was another error.

But I don't then defend the error, as you did.

Hmmm .... see I trimmed the signature here. Actually it's very easy to
use the reply link and forget trimming the content.

I never "defended" my error. I said including stdio.h was "obvious"
and I also agreed that getchar() returns an int. What I said was it
would "work in this case" .... which of course was later pointed out
to me as the most likely source of errors .... I even agreed to this.

Thanks for that link of http://www.c-faq.com. I've already added it to
my C Bookmarks list after seeing it being quoted extensively in this
forum.

[Eric Sosman]

BiGYaN wrote On 06/12/07 14:36,:

On Jun 12, 2:44 am, CBFalconer <[e-mail]:

>>BiGYaN wrote:

... snip ...

>>>Well I am a student of CS. I am here to learn and maybe help
others in the process too. So I really don't mind. But I must
confess, I never thought that this small snippet of code could
result in so many posts.

We can pick interminable holes in almost anything.

That's what I observe.

If you're sneering at the ability to identify tiny
flaws, don't. As a self-described Post Graduate CS
student you ought to know by now that computer programs
are "stiff" and "brittle," and that one tiny flaw can
bring an entire beautiful structure to ruin. If you
cannot spot those flaws, or take constructive action when
someone else spots them for you, you have invested a lot
of learning in a career for which you are unsuited.

One of the hardest lessons a programmer must learn
is that the correct response when someone finds flaws
in his beautifully-crafted code is "Thank you!"

--
Er*********@sun.com

[Richard Harter]

On Tue, 12 Jun 2007 09:57:45 -0700, Keith Thompson <ks***@mib.orgwrote:

>Urs Beeli <usenet@CONCAT_MY_FIRST_AND_LAST_NAME.chwrites:

>On Mon, 11 Jun 2007 11:36:07 +0000 Richard Heathfield wrote:

>> Urs Beeli said:

[...]

>I have profited incredibly from lurking in c.l.c and becoming a
nitpicker in my own code has made it more portable, safer and easier
to maintain.

I'm delighted to hear it. Do you want a job in clc's PR department? :-)

It depends on how well it pays :-)

That would be "no", then. 8-)}

That depends. Perhaps he will only consider the job if it doesn't pay
well.