scanf() vs gets()

[Richard Heathfield]

Re: scanf() vs gets()

CBFalconer wrote:
[color=blue]
> Teh Charleh wrote:[color=green]
>>[/color]
> ... snip ...[color=green]
>>[color=darkred]
>> > By the way, don't use gets(). It cannot be used safely, except
>> > by Dan Pop.[/color]
>>
>> 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![/color]
>
> 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,[/color]

It's actually called fgetline(). I'll tell you what - I'll link to your page
if you link to mine. Deal?
[color=blue]
> 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/>[/color]

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).
[color=blue]
> Please tell us the name, author, publisher etc. of your C book so
> that we can recommend burning it.[/color]

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 : binary@eton.pow ernet.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]

Re: [FAQs] scanf() vs gets()

"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message
news:Wnsyb.2049 7$n56.11086@new sread1.news.pas .earthlink.net. ..[color=blue]
>
> return 0; /* main() is *required* to return an int */[/color]

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]

Re: [FAQs] scanf() vs gets()

On Mon, 1 Dec 2003 20:22:04 +1100, in comp.lang.c , "Peter Nilsson"
<airia@acay.com .au> wrote:
[color=blue]
>"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message
>news:Wnsyb.204 97$n56.11086@ne wsread1.news.pa s.earthlink.net ...[color=green]
>>
>> return 0; /* main() is *required* to return an int */[/color]
>
>No user defined function is actually _required_ to return a value in C90 or
>C99, main() or otherwise.[/color]

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.c om/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]

Re: [FAQs] scanf() vs gets()

"Mark McIntyre" <markmcintyre@s pamcop.net> wrote in message
news:pb6msvk7ce 2p6ajv9343f6o87 9q5s0g74b@4ax.c om...[color=blue]
> On Mon, 1 Dec 2003 20:22:04 +1100, in comp.lang.c , "Peter Nilsson"
> <airia@acay.com .au> wrote:[color=green]
> >"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message
> >news:Wnsyb.204 97$n56.11086@ne wsread1.news.pa s.earthlink.net ...[color=darkred]
> >>
> >> return 0; /* main() is *required* to return an int */[/color]
> >
> >No user defined function is actually _required_ to return a value in C90[/color][/color]
or[color=blue][color=green]
> >C99, main() or otherwise.[/color]
>
> 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.[/color]

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.

....[color=blue]
> 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.[/color]

Well, ignorance is bliss...
[color=blue]
> Plus FWIW every compiler I've ever
> used emits an error when a nonvoid function fails to return a value.[/color]

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.]
[color=blue]
> This is hardly conclusive, but strong circumstantial evidence.[/color]

You are correct, it's hardly conclusive at all.
[color=blue]
> And in any events, failing to return a value from a fn you explicitly
> declared to return a value is just plain bad programming.[/color]

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]

Re: scanf() vs gets()

In <3FCA7A49.2449B 5E6@yahoo.com> CBFalconer <cbfalconer@yah oo.com> writes:
[color=blue]
>Teh Charleh wrote:[color=green]
>>[/color]
>... snip ...[color=green]
>>[color=darkred]
>> > By the way, don't use gets(). It cannot be used safely, except
>> > by Dan Pop.[/color]
>>
>> 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![/color]
>
>Never use gets. See the FAQ for reasons. Avoid scanf for
>interactive work.[/color]

scanf is far better than fgets for interactive work.

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

[John Bode]

Re: scanf() vs gets()

onegaitanteidan @aol.comnojunk (Teh Charleh) wrote in message news:<200311301 60312.03493.000 01568@mb-m29.aol.com>...[color=blue][color=green]
> >Why did you ignore Ben's (correct) advice to not use 'gets()'?[/color]
>
> 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!
>[color=green]
> >
> >The vast majority of programming books for sale are simply incorrect.[/color]
>[color=green]
> >< Someone should maybe think about writing a book that is actually correct -Id[/color]
> buy it!
>[color=green]
> >Use 'fgets()'.[/color]
>
> From what Ive been hearing, it look as though fgets is definately the way
> forward, thanks :)[/color]

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]

Re: [FAQs] scanf() vs gets()

On Mon, 1 Dec 2003 23:22:34 +1100, in comp.lang.c , "Peter Nilsson"
<airia@acay.com .au> wrote:
[color=blue]
>"Mark McIntyre" <markmcintyre@s pamcop.net> wrote in message
>news:pb6msvk7c e2p6ajv9343f6o8 79q5s0g74b@4ax. com...[color=green]
>> On Mon, 1 Dec 2003 20:22:04 +1100, in comp.lang.c , "Peter Nilsson"[color=darkred]
>> >
>> >No user defined function is actually _required_ to return a value in C90 or
>> >C99, main() or otherwise.[/color]
>>
>> 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.[/color]
>
>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.[/color]

My misunderstandin g. I understood your remark above to mean "you don't
have to return anything even if you declare the function to return
something".
[color=blue][color=green]
>> Plus FWIW every compiler I've ever
>> used emits an error when a nonvoid function fails to return a value.[/color][/color]
[color=blue]
>A 'diagnostic' I can understand, because implementations can emit those till
>the cows come home.[/color]

True.
[color=blue]
>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.[/color]

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?
[color=blue]
>[Note: C++ compilers are not C compilers.][/color]

Gee ! : -)
[color=blue][color=green]
>> This is hardly conclusive, but strong circumstantial evidence.[/color]
>
>You are correct, it's hardly conclusive at all.[/color]

*shrug*. You're twisting the english language to make a clever remark.
Hardly germane to the discussion.
[color=blue][color=green]
>> And in any events, failing to return a value from a fn you explicitly
>> declared to return a value is just plain bad programming.[/color]
>
>True, but it was quite common in K&R C:[/color]

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.c om/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]

Re: scanf() vs gets()

Richard Heathfield wrote:[color=blue]
> CBFalconer wrote:
>[/color]
.... snip ...[color=blue][color=green]
> >
> > 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,[/color]
>
> It's actually called fgetline(). I'll tell you what - I'll link to your page
> if you link to mine. Deal?
>[color=green]
> > 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/>[/color]
>
> 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).[/color]

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 (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Dan Pop]

Re: scanf() vs gets()

In <43618c0e.03120 10741.443bcc91@ posting.google. com> john_bode@my-deja.com (John Bode) writes:
[color=blue]
>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())[/color]
^^^^^^^^^^^^^^^ ^^^^^^^^
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.
[color=blue]
>or by writing to a dynamically resizable buffer.[/color]

In which case, it's simpler not to mess with fgets at all.
[color=blue]
>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.[/color]

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: Dan.Pop@ifh.de

[Dan Pop]

Re: [FAQs] scanf() vs gets()

In <3fcb328b@news. rivernet.com.au > "Peter Nilsson" <airia@acay.com .au> writes:
[color=blue]
>"Mark McIntyre" <markmcintyre@s pamcop.net> wrote in message
>news:pb6msvk7c e2p6ajv9343f6o8 79q5s0g74b@4ax. com...
>[color=green]
>> Plus FWIW every compiler I've ever
>> used emits an error when a nonvoid function fails to return a value.[/color]
>
>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.[/color]

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: Dan.Pop@ifh.de

[Joe Wright]

Re: scanf() vs gets()

Dan Pop wrote:[color=blue]
>
> In <43618c0e.03120 10741.443bcc91@ posting.google. com> john_bode@my-deja.com (John Bode) writes:
>[color=green]
> >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())[/color]
> ^^^^^^^^^^^^^^^ ^^^^^^^^
> 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.
>[color=green]
> >or by writing to a dynamically resizable buffer.[/color]
>
> In which case, it's simpler not to mess with fgets at all.
>[color=green]
> >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.[/color]
>
> 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.
>[/color]
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. :=)
[color=blue]
> 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.
>[/color]
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]

Re: scanf() vs gets()

Dan.Pop@cern.ch (Dan Pop) wrote in message news:<bqfuuj$qi j$5@sunnews.cer n.ch>...[color=blue]
> In <43618c0e.03120 10741.443bcc91@ posting.google. com> john_bode@my-deja.com (John Bode) writes:
>[color=green]
> >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())[/color]
> ^^^^^^^^^^^^^^^ ^^^^^^^^
> 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.[/color]

Additional calls to fgets() or other input routine of your choice.
Better?
[color=blue]
>[color=green]
> >or by writing to a dynamically resizable buffer.[/color]
>
> In which case, it's simpler not to mess with fgets at all.
>[color=green]
> >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.[/color]
>
> 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.
>[/color]

Which is why you wrap fgets() in a lot of other logic to build robust
I/O routines.
[color=blue]
> 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[/color]

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]

Re: scanf() vs gets()

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

Regards
shun


"Teh Charleh" <onegaitanteida n@aol.comnojunk > ¼¶¼g©ó¶l¥ó·s»D
:20031130150833 .03493.00001557 @mb-m29.aol.com...[color=blue]
> OK I have 2 similar programmes, why does the first one work and the second[/color]
does[color=blue]
> not? Basically the problem is that the program seems to ignore the gets[/color]
call if[color=blue]
> 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",a aa);
>
> 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",a aa);
> }[/color]

[CBFalconer]

Re: scanf() vs gets()

CBFalconer wrote:[color=blue]
> Richard Heathfield wrote:[color=green]
> > CBFalconer wrote:
> >[/color]
> ... snip ...[color=green][color=darkred]
> > >
> > > 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,[/color]
> >
> > It's actually called fgetline(). I'll tell you what - I'll link
> > to your page if you link to mine. Deal?
> >[color=darkred]
> > > 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/>[/color]
> >
> > 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).[/color]
>
> 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.[/color]

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 (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Richard Heathfield]

Re: scanf() vs gets()

dam wrote:
[color=blue]
> You can add a statement fflush(stdin) after scanf.[/color]

No, you can't. fflush only works on streams open for output or update.
Calling it on input streams invokes undefined behaviour.
[color=blue]
> It will clear the
> input buffer[/color]

The Standard offers no such guarantee.
[color=blue]
> and the gets work properly.[/color]

How will you protect the array from overflow?

--
Richard Heathfield : binary@eton.pow ernet.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