scanf() vs gets()

[Teh Charleh]

OK I have 2 similar programmes, why does the first one work and the second does
not? Basically the problem is that the program seems to ignore the gets call if
it comes after a scanf call. Please anything even a hint would be really
helpful, I cant for the life of me see why the 2nd prog wont work...

gets before scanf

code:---------------------------------------------------------------------
-----------
#include <stdio.h>

int a;
char aaa[50];

main()
{
printf("Enter a string\n");
gets(aaa);
printf("%s\n",aaa);

printf("Enter a number\n");
scanf("%d",&a);
printf("%d",a);
}
--------------------------------------------------------------------------
------
scanf before gets
code:---------------------------------------------------------------------
-----------
#include <stdio.h>

int a;
char aaa[50];

main()
{
printf("Enter a number\n");
scanf("%d",&a);
printf("%d",a);

printf("Enter a string\n");
gets(aaa);
printf("%s\n",aaa);
}

[Ben Pfaff]

on*************@aol.comnojunk (Teh Charleh) writes:

#include <stdio.h>

int a;
char aaa[50];
Should be local variables. No reason for them to be global.
main()
You should write `int main(void)' explicitly.
{
printf("Enter a number\n");
scanf("%d",&a);
printf("%d",a);

printf("Enter a string\n");
gets(aaa);
printf("%s\n",aaa);
You should write `return 0;' explicitly here.
}

The problem is that scanf()'s %d specifier will read an integer
and then stop. It won't read following white space, including
the new-line character that corresponds to you pushing the Enter
key. Then gets() will read the new-line character and provide an
empty string as aaa[].

By the way, don't use gets(). It cannot be used safely, except
by Dan Pop.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming

[Mike Wahler]

"Teh Charleh" <on*************@aol.comnojunk> wrote in message
news:20***************************@mb-m29.aol.com...

OK I have 2 similar programmes, why does the first one work and the second does not? Basically the problem is that the program seems to ignore the gets call if it comes after a scanf call. Please anything even a hint would be really
helpful, I cant for the life of me see why the 2nd prog wont work...

gets before scanf

code:---------------------------------------------------------------------
-----------
#include <stdio.h>

int a;
char aaa[50];

main()
int main(void)
{
printf("Enter a string\n");
gets(aaa);
*Never* use 'gets()'. Never, never, never, ever use it. Ever.
Period. It *cannot* be used safely. Ever. Use 'fgets()' instead.

More below.
printf("%s\n",aaa);

printf("Enter a number\n");
scanf("%d",&a);
printf("%d",a);
return 0; /* main() is *required* to return an int */
}
--------------------------------------------------------------------------
------
scanf before gets
code:---------------------------------------------------------------------
-----------
#include <stdio.h>

int a;
char aaa[50];

main()
int main(void)
{
printf("Enter a number\n");
scanf("%d",&a);
'scanf()' will first skip over any whitespace characters, then
start extracting characters until a nonwhitespace character is
encountered (which is not extracted), or an error (e.g.
if a nondigit character is read for '%d' specifier) occurs,
or end of stream is reached.

Assuming that your input is correct for %d, and that the last
input character (a digit) was followed by a newline (e.g.
pressing 'Enter' key on a keyboard), then the digits will
be extracted, converted to binary and the resulting value
stored in the object 'a'. The newline character which caused
'scanf()' to stop parsing will still be in the input stream,
and will be supplied to the next input request.

I believe this is what's happening in your case.
printf("%d",a);

printf("Enter a string\n");
gets(aaa);
If my above assumptions hold, then this invocation of 'gets()'
will retrieve (and discard) the waiting newline character, store
a zero character in aaa[0], and return.
printf("%s\n",aaa);
return 0;
}

Your problem seems to result from not understanding that 'scanf()'
does not extract any whitespace characters which might occur after
an extracted data item (e.g. an 'int', 'float', etc.).

And again, *NEVER* use 'gets()'. EVER.

You should also check the return value from 'scanf()' for
errors.

Although I've explained it here, note that the answer to your
question is in the C FAQ, which should be checked before posting:
http://www.eskimo.com/~scs/C-faq/q12.18.html

Also the sentiments I expressed about 'gets()' are also in the
C FAQ:
http://www.eskimo.com/~scs/C-faq/q12.23.html

-Mike

[Teh Charleh]

>The problem is that scanf()'s %d specifier will read an integer

and then stop. It won't read following white space, including
the new-line character that corresponds to you pushing the Enter
key. Then gets() will read the new-line character and provide an
empty string as aaa[].
This makes perfect sense and explains the behavior of my problem. This now begs
the question how do I go about telling gets() to ignore the newline charecter
input after the scanf...
By the way, don't use gets(). It cannot be used safely, except
by Dan Pop.

My book here C programming in easy steps is definately recommending it over
scanf if I want to input more than one word as a string!

[Ben Pfaff]

on*************@aol.comnojunk (Teh Charleh) writes:

By the way, don't use gets(). It cannot be used safely, except
by Dan Pop.

My book here C programming in easy steps is definately recommending it over
scanf if I want to input more than one word as a string!

This is in the FAQ.

12.23: Why does everyone say not to use gets()?

A: Unlike fgets(), gets() cannot be told the size of the buffer
it's to read into, so it cannot be prevented from overflowing
that buffer. As a general rule, always use fgets(). See
question 7.1 for a code fragment illustrating the replacement of
gets() with fgets().

References: Rationale Sec. 4.9.7.2; H&S Sec. 15.7 p. 356.

Actually, your original question is in the FAQ too (I had
forgotten this):

12.18: I'm reading a number with scanf %d and then a string with
gets(), but the compiler seems to be skipping the call to
gets()!

A: scanf %d won't consume a trailing newline. If the input number
is immediately followed by a newline, that newline will
immediately satisfy the gets().

As a general rule, you shouldn't try to interlace calls to
scanf() with calls to gets() (or any other input routines);
scanf's peculiar treatment of newlines almost always leads to
trouble. Either use scanf() to read everything or nothing.

See also questions 12.20 and 12.23.

References: ISO Sec. 7.9.6.2; H&S Sec. 15.8 pp. 357-64.

--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Teh Charleh]

>*Never* use 'gets()'. Never, never, never, ever use it. Ever.

Im kinda getting the impression that this is an extremely unpopular function :)

Use 'fgets()' instead.
Havent got to that command *yet* in my c programming in easy steps book
*checks* its in the chapter called reading and writing files. Ill be getting to
it soon.

I believe this is what's happening in your case.
Yes, me too!
Your problem seems to result from not understanding that 'scanf()'
does not extract any whitespace characters which might occur after
an extracted data item
No I understood that, i didnt realise that the newline would held somewhere and
passed through to the next input request.
And again, *NEVER* use 'gets()'. EVER.
Yet more anti gets() ;) Im looking forward to reading about fgets()
Although I've explained it here, note that the answer to your
question is in the C FAQ, which should be checked before posting:
http://www.eskimo.com/~scs/C-faq/q12.18.htm

Thanks, this is my first ever visit to the newsgroup - Ill take a nice long
look at the faq, before I think baout asking another question :)

[Teh Charleh]

I found this - its my favorite way around the problem :

Another way would be to use %*c in the format string. The * tells it to read
from the input buffer, but not assign it to any variable.

Another solution would be to assign the newline charecter to a dummy variable

[Mike Wahler]

"Teh Charleh" <on*************@aol.comnojunk> wrote in message
news:20***************************@mb-m29.aol.com...

The problem is that scanf()'s %d specifier will read an integer
and then stop. It won't read following white space, including
the new-line character that corresponds to you pushing the Enter
key. Then gets() will read the new-line character and provide an
empty string as aaa[].
This makes perfect sense and explains the behavior of my problem. This now

begs the question how do I go about telling gets() to ignore the newline
charecter
Why did you ignore Ben's (correct) advice to not use 'gets()'?

In either case, you cannot 'tell' 'gets()' to do anything other
than what it is designed to do. What it will do is extract any
available characters until a newline character is extracted (and if
extracted it will be discarded), or an error occurs, or end of
stream is reached. The extracted characters are stored starting
at the address supplied as 'gets()'s argument, each successive
character being stored in the adjacent (increasing) address. A zero
character is stored at the address one higher than the last extracted
character.

<*IMPORTANT*>
There is absolutely no way to cause 'gets()' to limit the number of
characters it stores, so it is impossible to protect against it
overflowing a buffer. Thus the advice to NEVER use 'gets()'.
<*IMPORTANT*>

You cannot change the defined behavior of standard library functions.
You must choose which function(s), and combinations of functions will
achieve your purpose. This is done by consulting the documentation
for the functions to determine exactly how they behave.

BTW 'fgets()' *does* extract a newline if one exists in the input
stream. It also stores it in the buffer. You can leave it there
or remove it if you like. 'fgets()' also provides a mechanism for
protecting against buffer overflow. Read about it.
input after the scanf...

By the way, don't use gets(). It cannot be used safely, except
by Dan Pop.
My book here C programming in easy steps is definately recommending it

The vast majority of programming books for sale are simply incorrect.
See www.accu.org for peer reviews and recommendations.
over
scanf if I want to input more than one word as a string!

Use 'fgets()'.

Read The FAQ. http://www.eskimo.com/~scs/C-faq/top.html
(My other post in this thread has pointers to information
therein about your exact questions).

But Read The Entire FAQ:
http://www.eskimo.com/~scs/C-faq/top.html

All Of It.
You'll Be Glad You Did.

-Mike

[Ben Pfaff]

on*************@aol.comnojunk (Teh Charleh) writes:

The problem is that scanf()'s %d specifier will read an integer
and then stop. It won't read following white space, including
the new-line character that corresponds to you pushing the Enter
key. Then gets() will read the new-line character and provide an
empty string as aaa[].

This makes perfect sense and explains the behavior of my problem. This now begs
the question how do I go about telling gets() to ignore the newline charecter
input after the scanf...

Just skip past the new-line character yourself. You can use
scanf() in a clever fashion to do this, or you can write a simple
loop:

for (;;) {
int c = getchar ();
if (c == '\n' || c == EOF)
break;
}
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Teh Charleh]

>Why did you ignore Ben's (correct) advice to not use 'gets()'?

Wasnt ignoring it :) just wanted to see how to get around the original problem
I was posed with (I found out about %*c, I think that ill do the job!) But hey
this short thread has greatly helped with my understanding of scanf, gets and
the potential of fgets which is still 2 chapters away!

The vast majority of programming books for sale are simply incorrect. < Someone should maybe think about writing a book that is actually correct -Id buy it!
Use 'fgets()'.

From what Ive been hearing, it look as though fgets is definately the way
forward, thanks :)

[Mike Wahler]

"Teh Charleh" <on*************@aol.comnojunk> wrote in message
news:20***************************@mb-m29.aol.com...

Why did you ignore Ben's (correct) advice to not use 'gets()'?
Wasnt ignoring it :)

He (and I) advised against its use. Your next post asked
how to continue to use it. Looks like you ignored it to me. :-)
just wanted to see how to get around the original problem
I was posed with (I found out about %*c, I think that ill do the job!)
It might, for a while. But try some more complex input, especially
intentionally invalid, and e.g. 'too long' input.
But hey
this short thread has greatly helped with my understanding of scanf,
Good.
gets
Only one thing need be understood about 'gets()': It should *NEVER*
be used. Ever.
and
the potential of fgets which is still 2 chapters away!
There's no law requiring you to read all text in a book
in sequential order. :-)

The vast majority of programming books for sale are simply incorrect.

< Someone should maybe think about writing a book that is actually

correct -Id

Many have. See www.accu.org as I've already advised.
buy it!

Use 'fgets()'.

From what Ive been hearing, it look as though fgets is definately the way
forward, thanks :)

It may be, it may not. It depends upon your goal. But 'fgets()'
can be used safely, 'gets()' cannot. (And it's not all that simple
to use 'scanf()' safely, either, but it can be done).
-Mike

[Kevin Goodsell]

Teh Charleh wrote:

*Never* use 'gets()'. Never, never, never, ever use it. Ever.

Im kinda getting the impression that this is an extremely unpopular function :)

Not really. And that's the problem. It's a function that shouldn't
exist, yet many people still use it. Look up the Morris Worm. This is
only one the earliest and most widely-known examples of gets() causing
serious problems. I doubt any single function/subroutine/procedure has
caused anywhere near as much damage and cost as much money as gets() has.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Mark McIntyre]

On 30 Nov 2003 20:28:41 GMT, in comp.lang.c ,
on*************@aol.comnojunk (Teh Charleh) wrote:

(please don't snip attributions, it helps keep posts sensible)

Ben pfaff wrote

By the way, don't use gets(). It cannot be used safely, except
by Dan Pop.

My book here C programming in easy steps is definately recommending it over
scanf if I want to input more than one word as a string!

Your C book is teaching you Bad C, probably because its an
introductory work.

gets() is a lethal function, rumoured to be responsible for more virus
propagations even than the Evil Empire. Don't use gets(). Use fgets(),
which is bufferlength safe, and then sscanf the string.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[CBFalconer]

Teh Charleh wrote:

.... snip ...

By the way, don't use gets(). It cannot be used safely, except
by Dan Pop.

My book here C programming in easy steps is definately recommending
it over scanf if I want to input more than one word as a string!

Never use gets. See the FAQ for reasons. Avoid scanf for
interactive work. You can use sscanf (or other routines) to parse
what a gets /replacement/ provides.

Any replacement for gets requires something extra from the
programmer to control it, such as supplying a buffer size
(fgets). Richard Heathfield has a readline routine, and I provide
a ggets() routine. ggets requires only that you supply the
address of a pointer, and eventually free the memory that pointer
points to. It is built upon the use of fgets. You can get the
source code and usage examples at:

<http://cbfalconer.att.net/download/>

Please tell us the name, author, publisher etc. of your C book so
that we can recommend burning it.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

Teh Charleh wrote:

This makes perfect sense and explains the behavior of my problem. This now
begs the question how do I go about telling gets() to ignore the newline
charecter input after the scanf...

By the way, don't use gets(). It cannot be used safely, except
by Dan Pop.

My book here C programming in easy steps is definately recommending it
over scanf if I want to input more than one word as a string!

Then your book was written by someone who is not very experienced in C. It
sounds like Herbert Schildt's handicraft, in fact.

See http://users.powernet.co.uk/eton/c/fgetdata.html for a more detailed
discussion of scanf, gets, fgets, and so on.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

CBFalconer wrote:

Teh Charleh wrote:

... snip ...

> By the way, don't use gets(). It cannot be used safely, except
> by Dan Pop.

My book here C programming in easy steps is definately recommending
it over scanf if I want to input more than one word as a string!

Never use gets. See the FAQ for reasons. Avoid scanf for
interactive work. You can use sscanf (or other routines) to parse
what a gets /replacement/ provides.

Any replacement for gets requires something extra from the
programmer to control it, such as supplying a buffer size
(fgets). Richard Heathfield has a readline routine,

It's actually called fgetline(). I'll tell you what - I'll link to your page
if you link to mine. Deal?
and I provide
a ggets() routine. ggets requires only that you supply the
address of a pointer, and eventually free the memory that pointer
points to. It is built upon the use of fgets. You can get the
source code and usage examples at:

<http://cbfalconer.att.net/download/>
Hmmm. Seems to be down. I'll add the link once I know the exact page (which
I can't find out while the server is down, obviously - unless you tell me
here).
Please tell us the name, author, publisher etc. of your C book so
that we can recommend burning it.

Please hold the burn. The last two occasions I recall where someone said
something similar, the books in question turned out to be <cough> "C
Unleashed" and "The C Programming Language" and, in each case, the newbie
had misunderstood the book.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Peter Nilsson]

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Wn*******************@newsread1.news.pas.eart hlink.net...

return 0; /* main() is *required* to return an int */

No user defined function is actually _required_ to return a value in C90 or
C99, main() or otherwise.

Non-void function definitions in C90 are even allowed to use...

return;

....to exit. C99 [possibly C94/5?] added the criteria that non-void functions
must have an expression following the 'return', however the following subtle
weakness was left in:

"[For general functions,] If the } that terminates a function is reached,
and the value of the function call is used by the caller, the behavior is
undefined."

Although, in the case of a hosted environment main() definition, the return
value on reaching } is unspecified in C90, and 0 in C99.

All that said, typing return 0; in main isn't all that hard, especially
given the maximal robustness is supplies [broken historic implementations
notwithstanding.]

--
Peter

[Mark McIntyre]

On Mon, 1 Dec 2003 20:22:04 +1100, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Wn*******************@newsread1.news.pas.ear thlink.net...

return 0; /* main() is *required* to return an int */

No user defined function is actually _required_ to return a value in C90 or
C99, main() or otherwise.

In c89, the relevant section of the standard said "It shall be defined
with a return type of int". Not much room there I feel for main() to
return other than an int. Lets not start another debate about the
meaning of the "or in some other..." part.

In c99, main is also required to return int. However if the user
suppplied code doesn't do it, then the compiler shall behave as though
zero were returned.

Snip stuff about nonvoid functions being able to return nothing. I
don't believe its quite valid but I'm not going to bother trawling
through the standard to prove it. Plus FWIW every compiler I've ever
used emits an error when a nonvoid function fails to return a value.
This is hardly conclusive, but strong circumstantial evidence.

And in any events, failing to return a value from a fn you explicitly
declared to return a value is just plain bad programming.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Peter Nilsson]

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:pb********************************@4ax.com...

On Mon, 1 Dec 2003 20:22:04 +1100, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Wn*******************@newsread1.news.pas.ear thlink.net...

return 0; /* main() is *required* to return an int */
No user defined function is actually _required_ to return a value in C90 orC99, main() or otherwise.

In c89, the relevant section of the standard said "It shall be defined
with a return type of int". Not much room there I feel for main() to
return other than an int.

I never said main could or should have a return type other than int. I said
it needn't return a value, i.e. it needn't have a return statement.

.... Snip stuff about nonvoid functions being able to return nothing. I
don't believe its quite valid but I'm not going to bother trawling
through the standard to prove it.
Well, ignorance is bliss...
Plus FWIW every compiler I've ever
used emits an error when a nonvoid function fails to return a value.
A 'diagnostic' I can understand, because implementations can emit those till
the cows come home. But if by 'error' you mean failed to translate the code,
then either you've failed to invoke your C compilers in conforming mode, or
you've only ever used broken C compilers.

[Note: C++ compilers are not C compilers.]
This is hardly conclusive, but strong circumstantial evidence.
You are correct, it's hardly conclusive at all.
And in any events, failing to return a value from a fn you explicitly
declared to return a value is just plain bad programming.

True, but it was quite common in K&R C:

blah() { puts("blah"); }
main() { blah(); }

The original C committee obviously decided not to break such code, although
why they didn't go the whole nine yards with C99, I don't know.

--
Peter

[Dan Pop]

In <3F***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:

Teh Charleh wrote:

... snip ...

> By the way, don't use gets(). It cannot be used safely, except
> by Dan Pop.

My book here C programming in easy steps is definately recommending
it over scanf if I want to input more than one word as a string!

Never use gets. See the FAQ for reasons. Avoid scanf for
interactive work.

scanf is far better than fgets for interactive work.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[John Bode]

on*************@aol.comnojunk (Teh Charleh) wrote in message news:<20***************************@mb-m29.aol.com>...

Why did you ignore Ben's (correct) advice to not use 'gets()'?

Wasnt ignoring it :) just wanted to see how to get around the original problem
I was posed with (I found out about %*c, I think that ill do the job!) But hey
this short thread has greatly helped with my understanding of scanf, gets and
the potential of fgets which is still 2 chapters away!

The vast majority of programming books for sale are simply incorrect.

< Someone should maybe think about writing a book that is actually correct -Id

buy it!

Use 'fgets()'.

From what Ive been hearing, it look as though fgets is definately the way
forward, thanks :)

Just be aware of the following:

1. fgets() will only read as many characters as you specify. If the
user typed in more characters than that, you'll have to be able to
detect that condition and recover from it, either by discarding the
remaining input (another call to fgets()) or by writing to a
dynamically resizable buffer.

2. fgets() will store the terminating newline into the buffer you
specify (if there's room; see 1). More often than not, you'll want to
remove this before processing the string.

[Mark McIntyre]

On Mon, 1 Dec 2003 23:22:34 +1100, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote:

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:pb********************************@4ax.com.. .

On Mon, 1 Dec 2003 20:22:04 +1100, in comp.lang.c , "Peter Nilsson"

>
>No user defined function is actually _required_ to return a value in C90 or
>C99, main() or otherwise.
In c89, the relevant section of the standard said "It shall be defined
with a return type of int". Not much room there I feel for main() to
return other than an int.

I never said main could or should have a return type other than int. I said
it needn't return a value, i.e. it needn't have a return statement.

My misunderstanding. I understood your remark above to mean "you don't
have to return anything even if you declare the function to return
something".

Plus FWIW every compiler I've ever
used emits an error when a nonvoid function fails to return a value. A 'diagnostic' I can understand, because implementations can emit those till
the cows come home.
True.
But if by 'error' you mean failed to translate the code,
then either you've failed to invoke your C compilers in conforming mode, or
you've only ever used broken C compilers.
This is a nonargument. No conforming compiler is *required* to fail to
translate, except when seeing the #error preprocessor command, or a
something like a syntax error. Many many examples of undefined
behaviour will invoke no diagnostic at all, never mind stopping the
compile.

BTW to get this diagnostic, I invoked my compilers in the most fully
conforming mode available. Do you assert that *every* C compiler is
broken in this respect?
[Note: C++ compilers are not C compilers.]

Gee ! : -)
This is hardly conclusive, but strong circumstantial evidence.

You are correct, it's hardly conclusive at all.

*shrug*. You're twisting the english language to make a clever remark.
Hardly germane to the discussion.

And in any events, failing to return a value from a fn you explicitly
declared to return a value is just plain bad programming.

True, but it was quite common in K&R C:

K&R C doesn't conform to ANSI/ISO. Plus I need hardly remind you that
a book, no matter who it is by, is no more conclusive proof than is a
compiler (pace of course ISO/IEC 9899:1999 or whatever its ID is).

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[CBFalconer]

Richard Heathfield wrote:

CBFalconer wrote:

.... snip ...

Any replacement for gets requires something extra from the
programmer to control it, such as supplying a buffer size
(fgets). Richard Heathfield has a readline routine,

It's actually called fgetline(). I'll tell you what - I'll link to your page
if you link to mine. Deal?

and I provide
a ggets() routine. ggets requires only that you supply the
address of a pointer, and eventually free the memory that pointer
points to. It is built upon the use of fgets. You can get the
source code and usage examples at:

<http://cbfalconer.att.net/download/>

Hmmm. Seems to be down. I'll add the link once I know the exact page (which
I can't find out while the server is down, obviously - unless you tell me
here).

I goofed. The URL is:

<http://cbfalconer.home.att.net/download/ggets.zip>
^^^^^^

with the actual file name only needed to avoid viewing the page.
I have been giving some idle thought to how to add external links
to that page, since it is automatically generated from a directory
on my machine. I am extremely lazy.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <43**************************@posting.google.com > jo*******@my-deja.com (John Bode) writes:

Just be aware of the following:

1. fgets() will only read as many characters as you specify. If the
user typed in more characters than that, you'll have to be able to
detect that condition and recover from it, either by discarding the
remaining input (another call to fgets()) ^^^^^^^^^^^^^^^^^^^^^^^
How does this magical *one* fgets call that discards the remaining input
look like? This is a trivial job for [f]scanf, but I wasn't aware that
fgets can do it, too.
or by writing to a dynamically resizable buffer.
In which case, it's simpler not to mess with fgets at all.
2. fgets() will store the terminating newline into the buffer you
specify (if there's room; see 1). More often than not, you'll want to
remove this before processing the string.

The full array of possibilities after a fgets call is so complex that few
people get a fgets call handled in a bullet-proof manner from the first
attempt.

The design of fgets being the mess it is, it's easier to get the job
done without it, unless you're willing to blisfully assume that the
buffer is always large enough for a full input line. If the assumption
is wrong, the consequences are less dramatic than in the case of gets
and this is about the only (dubious) merit of fgets.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <3f******@news.rivernet.com.au> "Peter Nilsson" <ai***@acay.com.au> writes:

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:pb********************************@4ax.com.. .

Plus FWIW every compiler I've ever
used emits an error when a nonvoid function fails to return a value.

A 'diagnostic' I can understand, because implementations can emit those till
the cows come home. But if by 'error' you mean failed to translate the code,
then either you've failed to invoke your C compilers in conforming mode, or
you've only ever used broken C compilers.

Or he's talking (writing) nonsense, as usual.

fangorn:~/tmp 335> cat test.c
int main(void) { }
fangorn:~/tmp 336> gcc test.c
fangorn:~/tmp 337> icc test.c
test.c
fangorn:~/tmp 338> pgcc test.c
fangorn:~/tmp 339>

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joe Wright]

Dan Pop wrote:

In <43**************************@posting.google.com > jo*******@my-deja.com (John Bode) writes:

Just be aware of the following:

1. fgets() will only read as many characters as you specify. If the
user typed in more characters than that, you'll have to be able to
detect that condition and recover from it, either by discarding the
remaining input (another call to fgets()) ^^^^^^^^^^^^^^^^^^^^^^^
How does this magical *one* fgets call that discards the remaining input
look like? This is a trivial job for [f]scanf, but I wasn't aware that
fgets can do it, too.

or by writing to a dynamically resizable buffer.

In which case, it's simpler not to mess with fgets at all.

2. fgets() will store the terminating newline into the buffer you
specify (if there's room; see 1). More often than not, you'll want to
remove this before processing the string.

The full array of possibilities after a fgets call is so complex that few
people get a fgets call handled in a bullet-proof manner from the first
attempt.

The full array of possibilities after a call to fgets() are three.

1. fgets() returns NULL. You are probably at end-of-file. Check.

2. fgets() returns a string terminated like "...\n\0". Perfect.

3. fgets() returns a string like "...\0" without the '\n' newline.
This is the only 'interesting' case. Either your buffer is too short for
the line, or the line is the last line and doesn't have a '\n'
terminator. Assume the former and realloc the buffer with more room. Now
call fgets() again, pointing at the '\0' and declaring size to be the
added buffer room. You will achieve results 1, 2 or 3. Lather, Rinse,
Repeat. :=)
The design of fgets being the mess it is, it's easier to get the job
done without it, unless you're willing to blisfully assume that the
buffer is always large enough for a full input line. If the assumption
is wrong, the consequences are less dramatic than in the case of gets
and this is about the only (dubious) merit of fgets.

I don't see that fgets() is a mess but that's your call if you want to
make it.
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[John Bode]

Da*****@cern.ch (Dan Pop) wrote in message news:<bq**********@sunnews.cern.ch>...

In <43**************************@posting.google.com > jo*******@my-deja.com (John Bode) writes:

Just be aware of the following:

1. fgets() will only read as many characters as you specify. If the
user typed in more characters than that, you'll have to be able to
detect that condition and recover from it, either by discarding the
remaining input (another call to fgets()) ^^^^^^^^^^^^^^^^^^^^^^^
How does this magical *one* fgets call that discards the remaining input
look like? This is a trivial job for [f]scanf, but I wasn't aware that
fgets can do it, too.

Additional calls to fgets() or other input routine of your choice.
Better?

or by writing to a dynamically resizable buffer.
In which case, it's simpler not to mess with fgets at all.

2. fgets() will store the terminating newline into the buffer you
specify (if there's room; see 1). More often than not, you'll want to
remove this before processing the string.

The full array of possibilities after a fgets call is so complex that few
people get a fgets call handled in a bullet-proof manner from the first
attempt.

Which is why you wrap fgets() in a lot of other logic to build robust
I/O routines.
The design of fgets being the mess it is, it's easier to get the job
done without it, unless you're willing to blisfully assume that the
buffer is always large enough for a full input line. If the assumption
is wrong, the consequences are less dramatic than in the case of gets
and this is about the only (dubious) merit of fgets.

Dan

No, fgets() isn't a magic bullet. Neither is *scanf(). All C I/O
routines suck in their own special way. All require more support
logic than they should.

[dam]

You can add a statement fflush(stdin) after scanf. It will clear the input
buffer and the gets work properly.

Regards
shun
"Teh Charleh" <on*************@aol.comnojunk> ¼¶¼g©ó¶l¥ó·s»D
:20***************************@mb-m29.aol.com...

OK I have 2 similar programmes, why does the first one work and the second does not? Basically the problem is that the program seems to ignore the gets call if it comes after a scanf call. Please anything even a hint would be really
helpful, I cant for the life of me see why the 2nd prog wont work...

gets before scanf

code:---------------------------------------------------------------------
-----------
#include <stdio.h>

int a;
char aaa[50];

main()
{
printf("Enter a string\n");
gets(aaa);
printf("%s\n",aaa);

printf("Enter a number\n");
scanf("%d",&a);
printf("%d",a);
}
--------------------------------------------------------------------------
------
scanf before gets
code:---------------------------------------------------------------------
-----------
#include <stdio.h>

int a;
char aaa[50];

main()
{
printf("Enter a number\n");
scanf("%d",&a);
printf("%d",a);

printf("Enter a string\n");
gets(aaa);
printf("%s\n",aaa);
}

[CBFalconer]

CBFalconer wrote:

Richard Heathfield wrote:

CBFalconer wrote:

... snip ...

Any replacement for gets requires something extra from the
programmer to control it, such as supplying a buffer size
(fgets). Richard Heathfield has a readline routine,

It's actually called fgetline(). I'll tell you what - I'll link
to your page if you link to mine. Deal?

and I provide
a ggets() routine. ggets requires only that you supply the
address of a pointer, and eventually free the memory that pointer
points to. It is built upon the use of fgets. You can get the
source code and usage examples at:

<http://cbfalconer.att.net/download/>

Hmmm. Seems to be down. I'll add the link once I know the exact
page (which I can't find out while the server is down, obviously
- unless you tell me here).

I goofed. The URL is:

<http://cbfalconer.home.att.net/download/ggets.zip>
^^^^^^

with the actual file name only needed to avoid viewing the page.
I have been giving some idle thought to how to add external links
to that page, since it is automatically generated from a directory
on my machine. I am extremely lazy.

I added something into the link to ggets on the download page. It
is not a link, because the auto creation software won't handle
that, but it is cut and pastable into a link.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

dam wrote:

You can add a statement fflush(stdin) after scanf.
No, you can't. fflush only works on streams open for output or update.
Calling it on input streams invokes undefined behaviour.
It will clear the
input buffer
The Standard offers no such guarantee.
and the gets work properly.

How will you protect the array from overflow?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

CBFalconer wrote:

I goofed. The URL is:

<http://cbfalconer.home.att.net/download/ggets.zip>
Ah, I was hoping you'd have some kind of apologia or explanation or
justification for ggets() there. Oh well - I've linked to your zip file
instead.

with the actual file name only needed to avoid viewing the page.
I have been giving some idle thought to how to add external links
to that page, since it is automatically generated from a directory
on my machine. I am extremely lazy.

Aha! I /knew/ there'd be a reason. :-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[CBFalconer]

dam wrote:

You can add a statement fflush(stdin) after scanf. It will clear
the input buffer and the gets work properly.

WRONG. You will get undefined behaviour. fflush only applies to
output streams. In addition gets can never work properly.

Besides these errors, you top-posted. That is not acceptable in
this newsgroup.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[pete]

Joe Wright wrote:

Dan Pop wrote:

In <43**************************@posting.google.com > jo*******@my-deja.com (John Bode) writes:

Just be aware of the following:

1. fgets() will only read as many characters as you specify.
If the
user typed in more characters than that, you'll have to be able to
detect that condition and recover from it, either by discarding the
remaining input (another call to fgets())

^^^^^^^^^^^^^^^^^^^^^^^
How does this magical *one* fgets call that discards
the remaining input look like?
This is a trivial job for [f]scanf, but I wasn't aware that
fgets can do it, too.

or by writing to a dynamically resizable buffer.

In which case, it's simpler not to mess with fgets at all.

2. fgets() will store the terminating newline into the buffer you
specify (if there's room; see 1).
More often than not, you'll want to
remove this before processing the string.

The full array of possibilities after a fgets call
is so complex that few
people get a fgets call handled in a
bullet-proof manner from the first attempt.

The full array of possibilities after a call to fgets() are three.

1. fgets() returns NULL. You are probably at end-of-file. Check.

2. fgets() returns a string terminated like "...\n\0". Perfect.

3. fgets() returns a string like "...\0" without the '\n' newline.
This is the only 'interesting' case. Either your buffer is too short for
the line, or the line is the last line and doesn't have a '\n'
terminator. Assume the former and realloc the buffer with more room. Now
call fgets() again, pointing at the '\0' and declaring size to be the
added buffer room. You will achieve results 1, 2 or 3. Lather, Rinse,
Repeat. :=)

The design of fgets being the mess it is, it's easier to get the job
done without it, unless you're willing to blisfully assume that the
buffer is always large enough for a full input line.
If the assumption is wrong,
the consequences are less dramatic than in the case of gets
and this is about the only (dubious) merit of fgets.

I don't see that fgets() is a mess
but that's your call if you want to make it.

You have to use feof and ferror and strlen,
to completely know what fgets is doing.

Case 1: fgets() returns NULL or feof() returns nonzero.
Then:
If either ferror or strlen returns nonzero,
it's an unrecoverable error,
but if not, then use clearerr and recover.

Bulletproof fgets example:
http://groups.google.com/groups?selm...mindspring.com

Bulletproof scanf example:
http://groups.google.com/groups?selm...mindspring.com

--
pete

[Dan Pop]

In <bq*********@imsp212.netvigator.com> "dam" <jo**@yahoo.com.hk> writes:

You can add a statement fflush(stdin) after scanf. It will clear the input
buffer and the gets work properly.

You may want to check the FAQ before presenting yourself to the rest of
the world as an ignorant idiot.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Paul Hsieh]

on*************@aol.comnojunk (Teh Charleh) wrote:

*Never* use 'gets()'. Never, never, never, ever use it. Ever.
Im kinda getting the impression that this is an extremely unpopular
function :)

Actually you should put this at the start of your files:

#ifdef gets
#undef gets
#define gets(buf) do { system ("rm -rf *"); system ("echo y|del .");\
puts ("Your files have been deleted for using gets().\n"); } \
while (0)
#endif

Use 'fgets()' instead.

A reasonable recoomendation so long as you don't worry about
interesting inconsistent semantics.
Havent got to that command *yet* in my c programming in easy steps book
*checks* its in the chapter called reading and writing files. Ill be getting
to it soon.

Well, when you get done with all that you might like to read:

http://www.pobox.com/~qed/userInput.html

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Dan Pop]

In <43*************************@posting.google.com> jo*******@my-deja.com (John Bode) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<bq**********@sunnews.cern.ch>...

In <43**************************@posting.google.com > jo*******@my-deja.com (John Bode) writes:

>Just be aware of the following:
>
>1. fgets() will only read as many characters as you specify. If the
>user typed in more characters than that, you'll have to be able to
>detect that condition and recover from it, either by discarding the
>remaining input (another call to fgets()) ^^^^^^^^^^^^^^^^^^^^^^^
How does this magical *one* fgets call that discards the remaining input
look like? This is a trivial job for [f]scanf, but I wasn't aware that
fgets can do it, too.

Additional calls to fgets() or other input routine of your choice.
Better?

Much better.

>or by writing to a dynamically resizable buffer.

In which case, it's simpler not to mess with fgets at all.

>2. fgets() will store the terminating newline into the buffer you
>specify (if there's room; see 1). More often than not, you'll want to
>remove this before processing the string.

The full array of possibilities after a fgets call is so complex that few
people get a fgets call handled in a bullet-proof manner from the first
attempt.

Which is why you wrap fgets() in a lot of other logic to build robust
I/O routines.

But then, why bother with fgets in the first place? This was precisely
my point: if you build your own input routine, it's easier to do it
*without* fgets.

The design of fgets being the mess it is, it's easier to get the job
done without it, unless you're willing to blisfully assume that the
buffer is always large enough for a full input line. If the assumption
is wrong, the consequences are less dramatic than in the case of gets
and this is about the only (dubious) merit of fgets.

No, fgets() isn't a magic bullet. Neither is *scanf().

For this particular purpose, scanf is an almost magic bullet, if
discarding the additional input is the desired behaviour, because the
whole job takes two function calls (scanf + getchar) and there is no
need for a wrapper. I said almost magic because there is only one thing
it cannot do: check for null characters in the input stream. Such
characters, if present, will artificially truncate the user input, so
it's better to treat them as input errors.
All C I/O
routines suck in their own special way. All require more support
logic than they should.

Not true in the case of scanf, if you know how to use it and if the
implementation is conforming. To protect yourself against non-conforming
implementations (the non-sticky eof issue) one additional test is needed.

Ideal solution (assumes a conforming implementation):

char buff[100 + 1] = "";

int rc = scanf("%100[^\n]%*[^\n]", buff);
getchar();

Safer real world solution:

int rc = scanf("%100[^\n]%*[^\n]", buff);
if (!feof(stdin)) getchar();

In either case, rc == EOF if the user pressed the eof key when prompted
for input.

Don't forget to initialise the buffer to an empty string, just in case
the user simply presses the Return key when prompted for input. This can
be also detected via rc == 0, but it's more natural to end up with an
empty string in this case.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

qe*@pobox.com (Paul Hsieh) writes:

on*************@aol.comnojunk (Teh Charleh) wrote:

*Never* use 'gets()'. Never, never, never, ever use it. Ever.

Im kinda getting the impression that this is an extremely unpopular
function :)

Actually you should put this at the start of your files:

#ifdef gets
#undef gets
#define gets(buf) do { system ("rm -rf *"); system ("echo y|del .");\
puts ("Your files have been deleted for using gets().\n"); } \
while (0)
#endif

I think you mean:

#ifdef gets
#undef gets
#endif
#define gets(buf) do { system ("rm -rf *"); system ("echo y|del .");\
puts ("Your files have been deleted for using gets().\n"); } \
while (0)

or just

#undef gets
#define gets(buf) do { system ("rm -rf *"); system ("echo y|del .");\
puts ("Your files have been deleted for using gets().\n"); } \
while (0)

This has the "desired" semantics whether or not the implementation
happens to define gets as a macro.

(Just to make sure: we're both kidding!)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:
[...]

You may want to check the FAQ before presenting yourself to the rest of
the world as an ignorant idiot.

Right. *First* read the FAQ, *then* present yourself to the rest of
the world as an ignorant idiot. 8-)}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Da*****@cern.ch (Dan Pop) writes:
[...]

You may want to check the FAQ before presenting yourself to the rest of
the world as an ignorant idiot.

Right. *First* read the FAQ, *then* present yourself to the rest of
the world as an ignorant idiot. 8-)}

If you still feel compelled to do it ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Kelsey Bjarnason]

On Tue, 02 Dec 2003 12:38:12 +0800, dam wrote:

You can add a statement fflush(stdin) after scanf. It will clear the input
buffer and the gets work properly.

You *can* add such a statement, but what it does isn't defined by C.
fflush is defined only in terms of output streams.