Can you initialize and assign pointers in the same instance?

Quote:

---

Originally Posted by yougene

I know getchar() isn't a good choice but I actually tried scanf before I tried this.. Oddly, I get the exact same result no matter which one I use.

That 0 isn't entered by me, it's entered on it's own. Why is that?

---

The same reason, and the answer was in the first link.

You type a newline and it is not consumed by %s, so it's there ready and waiting for either scanf of a char or the getchar. This satisfies that call immediately without needing further entry from the user.

[edit]Searching for this newline amongst the ds produces no matches and you output 0 matches found.[/edit]

Code:

---

  char string1[ 50 ] = { };
  char string2[ 50 ] = { };
  char string3[ 50 ] = { };

---

The empty braces for the string initialization looks strange to me, and my compiler emits:

Quote:

---

../main.c:12: warning: ISO C forbids empty initializer braces
../main.c:13: warning: ISO C forbids empty initializer braces
../main.c:14: warning: ISO C forbids empty initializer braces

---

Put a zero between the braces or "" and it would appear more normal.

And this:

Code:

---

  char character = " ";

---

tries to stuff two characters into one.

I had the same question too, about the empty braces, and yes it compiles and zeros the area. With gcc -Wall -pedantic there is no warning about that, but i guess it would be an error with -ansi.

The reason for the empty spaces is because I didn't know what to put in there in the context of char data types. I didn't know if random garbage data could possibly effect my program. I'm not that experienced with C and I'm not learning it in a classroom setting( yet ) so I'm probably missing alot of stuff most people would know.

When FAQ talks about buffer, it's talking about the input buffer? Stuff left over in the buffer is kept there until the next time, input is required? How long is it kept there?

Also p replaces \n with \0. Wouldn't the \0 simply be appended to the next output the same way \n is? Or am I missing something?

Quote:

---

Originally Posted by yougene

The reason for the empty spaces is because I didn't know what to put in there in the context of char data types. I didn't know if random garbage data could possibly effect my program. I'm not that experienced with C and I'm not learning it in a classroom setting( yet ) so I'm probably missing alot of stuff most people would know.

When FAQ talks about buffer, it's talking about the input buffer? Stuff left over in the buffer is kept there until the next time, input is required? How long is it kept there?

---

Until the heat death of the universe, or your program ends, whichever comes first. (Or of course you read it in.)

Quote:

---

Originally Posted by yougene

Also p replaces \n with \0. Wouldn't the \0 simply be appended to the next output the same way \n is? Or am I missing something?

---

I don't know what p is supposed to be in this context. And what do you mean by appended to the next output?

Code:

---

  scanf( "%s", string1 );

---

http://cboard.cprogramming.com/showp...37&postcount=9

Quote:

---

Originally Posted by tabstop

I don't know what p is supposed to be in this context. And what do you mean by appended to the next output?

---

I probably should have said appended to input, not ouput.

I was referring to the FAQ link posted earlier

Code:

---

int main()
{
  char buf[BUFSIZ];
  char *p;
 
  printf ("Please enter a line of text, max %d characters\n", sizeof(buf));
 
  if (fgets(buf, sizeof(buf), stdin) != NULL)
  {
    printf ("Thank you, you entered >%s<\n", buf);
   
    /*
    *  Now test for, and remove that newline character
    */
    if ((p = strchr(buf, '\n')) != NULL)
      *p = '\0';
     
    printf ("And now it's >%s<\n", buf);
  }
 
  return 0;
}


/*
 Program output:

Please enter a line of text, max 512 characters
this is a test
Thank you, you entered >this is a test
<
And now it's >this is a test<
*/

---

I didn't realize scanf was at risk for buffer over-run as well. I guess that's what this is as well. Although changing it to %49s doesn't directly address the problem.

Quote:

---

Originally Posted by yougene

I didn't realize scanf was at risk for buffer over-run as well. I guess that's what this is as well. Although changing it to %49s doesn't directly address the problem.

---

Perhaps not. But it will make the program securer and avoid situations where buffer overruns are possible. And avoid undefined behavior which is always a good thing. One less thing to worry about.