Allright then. So if I understand correctly the following should be done:
To get one line from the user?Code:char input [25];
char iPtr = input;
fgets(iptr, 25, stdin);
Printable View
Allright then. So if I understand correctly the following should be done:
To get one line from the user?Code:char input [25];
char iPtr = input;
fgets(iptr, 25, stdin);
Yes. The first argument specifies a buffer to use, like you do.
The second argument tells the maximum amount of characters fgets can read before stopping.
And the third indicates where it should read from - to read from the user, stdin is typically used.
25 characters max be a little too little. Perhaps try extending it to 100 or more. And there you go.
Note that fgets() leaves the terminating newline (if any) in place, while gets() does not -- so if you want a drop-in replacement for gets() (with a length parameter, of course), consider something like this.
Note that I've added error checking and a return value, which you could leave out if you wanted to. Also, I've used size_t, which is the preferred type for referencing string indicies. (You can use int if it makes you feel better. :) ) A simpler version:Code:#include <stdio.h> /* for fgets() */
#include <string.h> /* for strchr() */
char *get_string(char *buffer, size_t len) {
char *p;
/* get a line of input, returning NULL on failure */
if(!fgets(buffer, len, stdin)) return NULL;
p = strchr(buffer, '\n'); /* search for a newline */
if(p) *p = 0; /* if there was a newline, terminate the string there, erasing it */
return buffer; /* just for compatibility with gets() and fgets() */
}
Also see: http://cpwiki.sourceforge.net/GetsCode:void get_string(char *buffer, int len) {
fgets(buffer, len, stdin);
p = strchr(buffer, '\n');
if(p != NULL) *p = '\0';
}
How big the buffer should be is quite dependent on what you are asking for, right? If you expect the user to answer yes or no, you could get away with 4. If you are asking for a first name, you probably need about 20 to cover those lengthy double-names that are used in some places. For a full name (first + last), you are probably ok with 30-40 chars.
What does make sense, however, is to write a function like dwks's, but also add a "clear the input buffer if too much input". There is of course nothing stopping a person from typing in "ajkhkfhkasdhfkasdhksdh" as the answer to "Yes or No" type question, and then you end up with "rubbish" in the input buffer. It's not really a problem that "ajk" isn't "Yes" or "No", but the fact that it will continue reading out 3 chars at a time saying "That's not yes or no"....
--
Mats
Strangely enough, there's also a page on cpwiki about that, too. :) Clearing the input buffer, that is. http://cpwiki.sourceforge.net/Pause_console
(The topic name's not quite right, though . . . .)
[QUOTE=omnificient;722179]I've been playing a bit with pointers and strings.
Code:#include <stdio.h>
int main()
{
char string; //Sets up a character named string.
char * pString = &string; //Makes a character pointer and assings the adress of string to it
puts("Enter: ");
scanf(" %s", pString); //I know this could have been gets(), I used scanf().
[snipped]
I think (though I did not test), this program should fault, because you are reading input and storing at address of "string". You perhaps want to rewrite it as:
Thanks,Code:int main()
{
char string[SOME_NUM]; //Sets up a character named string.
char * pString = string; //Makes a character pointer and assings the adress of string to it
puts("Enter: ");
scanf(" %s", pString); //I know this could have been gets(), I used scanf().
...
}
Vijay Zanvar
http://faq.zanvar.in/category/pointers-and-arrays/
>And whilst it's likely that there are systems where a void * is different from a char *
Not passing a pointer to void to printf with %p is always undefined behavior. If it for you on your particular implementation, fine, but I'll add the cast and be confident that there won't be problems.
>I doubt the original poster's problem will be solved by a type-cast.
Oddly enough, I wasn't trying to solve the OP's problem, I was correcting a mistake in one of the OP's examples.