another way to clear the buffer

So in my book they gave this example of how to control the garbege from scanf

Code:

ex: while ( (scanf("%d", &input) !=1) scanf("%*s");

I understand the fact that it skips to the next whitespace in STDIN queque . what I don't understand is how when I try to get the garbege out with

Code:

while ( (ch = getchar())!='\n') printf("%c is not an integer", ch);

nothing seems to come out..

how is it that the buffer seems to be cleared out. I thought the "*" operator only skipped over it. isn't it still in the buffer when it skips over, or does it just ignore the input period and doesn't read anything.

Mabey this will help http://faq.cprogramming.com/cgi-bin/...&id=1043284392

not really. but thanks. I know how to flush the buffer, I'm just wonderign if when scanf reads that code with the "*" operator. Does it skip over to the next whitespace without even reading the string, or is the string in the buffer still. It doesn't seem to be, but I can't be sure.

The * reads the conversion like it normally would in any other instance, but rather than saving it in a variable, it discards it. It's a "read but don't save" specifier.

Quzah.

I see somone determined to learn that using scanf() with any degree of safety is a painful experience ;)

I think you've got the message now caroundw5h

Code:

char buff[BUFSIZ]; while ( fgets( buff, BUFSIZ, stdin ) != NULL ) { // use sscanf() on buff. If it contains junk just complain and // go round again. fgets() will get a new line with no unpleasant // aftertaste of unflushed garbage characters. }

Quote:

Originally Posted by Salem

I see somone determined to learn that using scanf() with any degree of safety is a painful experience ;)

I think you've got the message now caroundw5h

Code:

char buff[BUFSIZ]; while ( fgets( buff, BUFSIZ, stdin ) != NULL ) { // use sscanf() on buff. If it contains junk just complain and // go round again. fgets() will get a new line with no unpleasant // aftertaste of unflushed garbage characters. }

Yes, fgets() is safe and clean for the purpose (getting information from the user). Just keep in mind that the trailing '\n' is placed into the destination buffer when there is room enough. If the input is greater than the given size, the trailing '\n' is missing.

The ususal trick to manage it is :

Code:

fgets (buf, ...); { /* search the '\n' */ char *p = strchr (buf, '\n'); if (p != NULL) { /* found : kill it. */ *p = 0; } else { /* not found : error handling */ /* one option is to flush the stream * (ignore the extra characters) */ int c; while ((c = fgetc (stream)) != '\n' && c != EOF) { } } }

Of course, you are not going to add all that stuff each time you use fgets(). This is the reason why it is recommended to build your own reusable 'getline' (or whatever) function, based on this code.

For example:

Code:

char *getline (char *buf, size_t size, FILE *stream);

that returns buf (ok) or NULL (error)

or

Code:

int getline (char *buf, size_t size, FILE *stream);

that returns 0 (ok) or different meaningful error values...

>>If the input is greater than the given size, the trailing '\n' is missing.
>>/* not found : error handling */
There's an additional consideration too, that would involve fgets() not putting a \n into the buffer, but the input was acceptable. This is when the line of input doesn't actually contain a \n, for example, the last line in a file might not do so. Invoking error handling and ignoring the input in this condition could be deemed incorrect (Eg: your compiler ingores your last line of C code in your source file).

Thanks for the help guys.

Quote:

Originally Posted by Salem

I see somone determined to learn that using scanf() with any degree of safety is a painful experience ;)

I think you've got the message now caroundw5h

:p , I understand when I started C it was gonna be messy. but i didn't know how messy. Its cool though. I don't want to run away from a function just because I don't understand it. I want to understand the Why's of it all. with understanding I believe comes more options..

Besides C is all about the internals. I want to know what's under the hood. Thats why Caround W5(who,what,where,when,why) H (how.)

I ain't scared ano C :D

>I want to understand the Why's of it all.
Most of the time, understanding only comes from building on knowledge gained from experience. Not understanding something doesn't mean you should study it until you know it inside and out. Learn the parts that would be most useful to you, then later when you have more experience you'll be in a better position for complete understanding. Without getting hopelessly lost. ;)

Quote:

Originally Posted by caroundw5h

I understand when I started C it was gonna be messy. but i didn't know how messy. Its cool though. I don't want to run away from a function just because I don't understand it.

Understanding how to use scanf() properly is quite a challenge. A very few number of professional programmers have wasted their time for that, because simple and safe alternatives exist.

Now, it's up to you.

Quote:

Originally Posted by Emmanuel Delaha

Understanding how to use scanf() properly is quite a challenge. A very few number of professional programmers have wasted their time for that, because simple and safe alternatives exist.

Now, it's up to you.

I hear what your saying, and I will heed you and prelude's advice, but using that same argument, ppl might as well give up C for certain tasks because "simple and safe alternatives exist"

>ppl might as well give up C for certain tasks because "simple and safe alternatives exist"
You're saying this isn't the case? C isn't ideal for every task, so if there's a better alternative then why not use it? ;)

Quote:

Originally Posted by Prelude

>ppl might as well give up C for certain tasks because "simple and safe alternatives exist"
You're saying this isn't the case? C isn't ideal for every task, so if there's a better alternative then why not use it? ;)

I do. Its called python.

Thats all i'm gonna say. :D