Discuss Clearing the input buffer (stdin) in the C Programming forum on Dev Shed. Clearing the input buffer (stdin) C programming forum discussing all C derivatives, including C#, C++, Object-C, and even plain old vanilla C. These languages are low level languages, and used on projects such as device drivers, compilers, and even whole computer operating systems.
Posts: 1,286
Time spent in forums: 3 Weeks 3 Days 6 h 10 m 16 sec
Reputation Power: 173
Clearing the input buffer (stdin)
Hi guys,
I'm trying to learn C (wht varying results, ), and I'm trying to input 2 strings of a fixed length (so I'm using fgets so as not to get buffer overflows) into 2 seperate character arrays, and then print them out (nothing too complex).
Anyway, what I'm trying to figure out is how to clear the input buffer, because if you input more than 16 bytes it stays in the stdin buffer, and so the user isn't asked for more data a second time.
I've tried using fflush(stdin) (even though its not supposed to clear input buffers), fseeking to the end of the stream (which I thought should have worked...), and also rewinding as well, none of those attempts have worked. So yeah, if anyone can explain to me how i should go about cleaing stdin, I'd appreciate it.
I've thought of doing something like checking if there's a new line inside the first variable, and if so, then your buffer is clear, but if there isn't either keep fgets()-ing of fgetc()-ing untill you get a new line character, and once you do stop and free your buffer into which you've been either fgets/c()-ing into.
But I would have thought there'd be some kind of built in function which would do what I needed it to.
I'm compiling with GCC 3.3.6 under Slackware 10.2, if that helps...
Also I get the following warnings when compiling:
Code:
malloc.c: In function `main':
malloc.c:8: warning: assignment makes pointer from integer without a cast
malloc.c:9: warning: assignment makes pointer from integer without a cast
And since I'm new to C I have no idea what I should do (I'm guessing malloc returns an integer and I needed to cast it to a pointer or something, but thats a guess)....and since the guide I'm learning from (http://beej.us/guide/bgc/output/html/index.html) has code which generates the same warning, I'm not sure what I should do....
Posts: 8
Time spent in forums: 2 h 17 m 39 sec
Reputation Power: 0
to help ya out a little with the warnings you are getting, all you nead to do is cast your malloc, and since your variables are char *, go at it like that.
Code:
...
char *c, *d;
c = (char *)malloc (16);
d = (char *)malloc (16);
...
Thanks, that works, is there much overhead with getting data character by character from the input, rather than getting chunks and then searching then?
Also, i was wondering if there's anhything wrong with defining a macro in the preprocessor to do this (so that I don't have to trype that whole thing out every time, and don't get any function overhead) like so:
to help ya out a little with the warnings you are getting, all you nead to do is cast your malloc, and since your variables are char *, go at it like that.
Code:
...
char *c, *d;
c = (char *)malloc (16);
d = (char *)malloc (16);
...
That solves my warnings, but Dave seems to think there's something wrong with that it seems.....So if anyone would care to enlighten me?
And if anyone can be bothered to explain, could someone tell me what problems I could have run into if I hadn't cast them to pointers?
Posts: 1,286
Time spent in forums: 3 Weeks 3 Days 6 h 10 m 16 sec
Reputation Power: 173
Quote:
Originally Posted by Dave Sinkula
getchar returns an int -- and does so for a reason. The variable you declare ought to be the correct one (int).
Whoops, I should read things carefully next time, thanks.
Quote:
Originally Posted by Dave Sinkula
Use a do...while(0) loop for a macro.
Should I take that in blind faith, or is there a reason behind that? Also, do you mean do...while(1) loop? Because I'm not sure how I would implement a do...while(0) loop, and still have it loop.....I'm an absolute beginner here....
Quote:
Originally Posted by Dave Sinkula
Use a C compiler for C code, rather than a C++ compiler for C code. Doing so relieves much grief.
Isn't gcc a C compiler as well as a C++/Java/Fortan/Ada/objective-C compiler? Or should I just be using something which only supports c files, because as I understand it, if the file gcc is getting is a *.c file (which is what I'm doing) it will parse it like a C file, not a C++ file. Maybe I should I just use cc malloc.c instead of gcc malloc.c?
Posts: 3,907
Time spent in forums: 2 Months 3 Weeks 4 Days 1 h 39 m 56 sec
Reputation Power: 1774
> And if anyone can be bothered to explain, could someone tell me what problems I could have run into if I hadn't cast them to pointers?
Well in C, there is no good reason to cast the return result of malloc.
The only thing it can achieve is hiding possible errors.
For example, you originally posted
> c = malloc (16);
And got
malloc.c:8: warning: assignment makes pointer from integer without a cast
Which is indeed correct for your code, because the error in your code was the lack of #include <stdlib.h>
The C compiler generated an implicit
int malloc();
instead.
Now, if you come along and try and fix this warning with something dumb like
c = (char *)malloc (16);
The error message goes away, but the reason for it doesn't.
You now have a forced (and unchecked) int to pointer conversion (the compiler having implicitly generated int malloc() ). On machines with different sized pointers and integers, the code is now seriously broken.
Now, even if you have
Code:
#include <stdlib.h>
...
c = malloc (16);
and you compile this with a C++ compiler, you get an entirely different warning, one about converting a void* into another pointer type. Of course, if it is your intent to write C++, then you should be using new/delete for dynamic memory not malloc/free.
> Isn't gcc a C compiler as well as a C++/Java/Fortan/Ada/objective-C compiler?
GCC (all upper case) is the GNU Compiler Collection, which is all those things you list.
gcc (all lower case) is the GNU C Compiler
g++ is the GNU C++ Compiler
If you're using
gcc prog.c
then it's pretty certain that you're compiling C code with a C compiler.
> #define CLEARBUF() char ch; while ((ch = getchar()) != '\n' && ch != EOF);
Since fgets() also reads newlines, you have to press an extra enter just to get past the CLEARBUF if the user types in a short line.
Always read into a temporary buffer, and then validate and move the data to where you need it to be inside the code proper, not inside the input routine.
BUFSIZ is a standard constant in stdio.h
Posts: 1,286
Time spent in forums: 3 Weeks 3 Days 6 h 10 m 16 sec
Reputation Power: 173
Quote:
Originally Posted by salem
> And if anyone can be bothered to explain, could someone tell me what problems I could have run into if I hadn't cast them to pointers?
Well in C, there is no good reason to cast the return result of malloc.
The only thing it can achieve is hiding possible errors.
For example, you originally posted
> c = malloc (16);
And got
malloc.c:8: warning: assignment makes pointer from integer without a cast
Which is indeed correct for your code, because the error in your code was the lack of #include <stdlib.h>
The C compiler generated an implicit
int malloc();
instead.
Now, if you come along and try and fix this warning with something dumb like
c = (char *)malloc (16);
The error message goes away, but the reason for it doesn't.
You now have a forced (and unchecked) int to pointer conversion (the compiler having implicitly generated int malloc() ). On machines with different sized pointers and integers, the code is now seriously broken.
Now, even if you have
Code:
#include <stdlib.h>
...
c = malloc (16);
and you compile this with a C++ compiler, you get an entirely different warning, one about converting a void* into another pointer type. Of course, if it is your intent to write C++, then you should be using new/delete for dynamic memory not malloc/free.
Thanks for all that. I'm not planning on writing C++ atm, so its not an issue right now, thanks for the tip anyway.
Quote:
Originally Posted by salem
> Isn't gcc a C compiler as well as a C++/Java/Fortan/Ada/objective-C compiler?
GCC (all upper case) is the GNU Compiler Collection, which is all those things you list.
gcc (all lower case) is the GNU C Compiler
g++ is the GNU C++ Compiler
If you're using
gcc prog.c
then it's pretty certain that you're compiling C code with a C compiler.
Well, doing man gcc gives the man file for the compiler collection, so I'm not sure, but cc prog.c works, so I'll just use that now (unless its a bad idea...)...
Quote:
Originally Posted by salem
> #define CLEARBUF() char ch; while ((ch = getchar()) != '\n' && ch != EOF);
Since fgets() also reads newlines, you have to press an extra enter just to get past the CLEARBUF if the user types in a short line.
Always read into a temporary buffer, and then validate and move the data to where you need it to be inside the code proper, not inside the input routine.
BUFSIZ is a standard constant in stdio.h
Right, thanks for that! I take it that once the user enters BUFSIZ bytes, it just stops accepting it, and since the user can't press enter they have to press backspace (so there's space in the input buffer for the new line) and then enter , opr at least that what happens for me, I'm wdonering if this is consisten behaviour among OSs?
Anyways, I implemented the buffer in which to read into, but I'm not sure wether it would be better to use my own function for copying strings, and then copy it char-by-char untill you get to a new line char, where you copy a NUL byte over instead, or if I should just copy the string using strncopy, and then check if the last character is a new line, and if it is replace it with a NUL character?
Posts: 1,676
Time spent in forums: 1 Month 3 Days 8 h 23 m 46 sec
Reputation Power: 132
Quote:
Originally Posted by kuza55
Should I take that in blind faith, or is there a reason behind that? Also, do you mean do...while(1) loop? Because I'm not sure how I would implement a do...while(0) loop, and still have it loop.....I'm an absolute beginner here....