Hi I just started learning C programming in gcc compiler on my Debian system. Here is the code
main()
{
fflush( stdin );
int a,b;
scanf("%d,%d",&a,&b);
printf("%d,%d",a,b);
}
The scanf doesn't take input for the second variable. I press 2 and then return key and it displays
root#debian:/home/wis# ./test
2
2,0root#debian:/home/wis#
I have used space and tab key also. Please help me.
You defined your scanf string as "%d,%d", so the program expect an input like 1,2.
If you give it only one digit and press Enter, it parses the first digit and leaves the second one untouched. It was assigned 0 on declaration, so that's what you are seeing when printing.
Your printf statement would benefit from an "\n" at the end, and your code snippet needs indentation. Please show your includes (#include <stdio.h>) next time, it makes it easier for us to compile and run the code.
Related
printf("%c %c", getc(stdin), getc(stdin));
rewind(stdin); printf("\n");
printf("%c %c", getchar(), getchar());
output
s
s
s
s
I wrote the source code like that and I pressed s, enter, s, enter sequentially on windows console application using vs2017. Console shows me what I put and print output when I press the key. The result's appearance is like s, enter, enter, space, s, s, enter, enter, space, s. Did I use the function in wrong way?
Q1. I pressed s, enter sequentially, but why output is reversed?
Q2. At output's third line and sixth line, why is there exist whitespace like s not s?.
Explaining the output
The arguments to a function can be evaluated in any order that the compiler chooses.
The original code looked like this (missing printf("\n"); compared to the revised code):
printf("%c %c", getc(stdin), getc(stdin));
rewind(stdin);
printf("%c %c", getchar(), getchar());
Your 'output' in the question is extremely difficult to read and interpret. However, I'm reasonably sure that what you show consists of both your input and the program's output.
You say you type s enter twice. The output you get, copied from the question, is:
s
s
s
s
The first s and the newline that follows are what you typed. The blank line is there because the newline was read by the getc(stdin) that appears first in the argument list, then there's the blank from the format string, and the s which was read by the getc(stdin) that appears second in the argument list. Your compiler, it seems, evaluates the arguments right to left — but you should not rely on that.
Now we run into a problem; there's a newline after the second s that isn't accounted for by the code you showed when I wrote this answer. Since then, you've added the printf("\n"); which explains the output you saw.
Putting that aside, the third s is followed by a newline and is what you typed. And again, the blank line is from the newline and then space and s is the rest of the output, and there's probably a newline after that too.
JFTR, when I run your code (program getc73 compiled from getc73.c), I see:
$ getc73
s
ss
s$
$
The $ is my prompt; the first s is what I type; then the newline, blank and s are printed (with no newline at the end); then the second s on the third line is my next s and return, followed by the newline and blank s. Since there's no newline at the end, my prompt appears immediately after the fourth s. I hit return to print another prompt at the start of the line.
Why rewind(stdin) is a no-op
You can't successfully execute an fseek() call on a terminal device. They don't have any storage so you can't move around like that. The rewind() function is effectively:
void rewind(FILE *fp)
{
fseek(fp, 0, SEEK_SET);
}
So, the rewind(stdin) call fails to rewind, but it has no way to report that to you because it returns no value. It does no good; it doesn't do any harm either. If it had worked, you would not have needed to enter the information twice.
If the standard input had been a file instead of a terminal, then the rewind would succeed — disks are seekable.
Improved formatting
If you were on a POSIX system, I'd suggest you used a feature of POSIX printf() that allows you to print the same argument more than once:
#include <stdio.h>
int main(void)
{
printf("[%1$c] %1$d [%2$c] %2$d\n", getc(stdin), getc(stdin));
printf("[%1$c] %1$d [%2$c] %2$d\n", getchar(), getchar());
return 0;
}
When I run that on my terminal (it's a Mac running macOS Mojave 10.14.6 using GCC 9.2.0), I get:
s
[
] 10 [s] 115
s
[
] 10 [s] 115
The lines with just the s on them are what I typed; the other lines show that the newline is printed before the letter s.
This probably won't work for you in VS2017 — the manual for printf() formats on Windows strongly suggests it won't work. Your best bet, probably, is to use:
#include <stdio.h>
int main(void)
{
printf("%d %d\n", getc(stdin), getc(stdin));
printf("%d %d\n", getchar(), getchar());
return 0;
}
That generates:
s
10 115
s
10 115
Choosing a good format to show what you're seeing is an art form. Don't forget to include newlines at the end of (most) printf() format strings. Obviously, if you're building up a line of output piecemeal, you don't want newlines at the end of intermediate formats, but the majority of printf() statements should have a newline at the end of the format.
scanf not working as expected with a normal input character
So I was just trying out the scanf() and a normal input/output of this function. I know that I had to leave a space before the input character and the operand% so my code is as below. Somehow I don't understand why whatever the input I inserted the output remains 0.
#include<stdio.h>
int main()
{
char c ;
scanf(" %c",&c);
printf("%c",c);
return 0;
}
I was expecting the output will be whatever the character I insert. For example, insert an "A" via keyboard and the output will be exactly an "A".
I'm using a vim environment to edit my code, but I found that if I run this code on codeblocks it works. What's the difference?
It appears you are not providing any non-whitespace (which are eaten away by th space in the format string, including newlines) characters (or perhaps nothing at all) from standard input. If this happens, scanf will fail to parse a char and leaves c uninitialized.
Using uninitialized variable is is Undefined Beheavior, so in theory anything could happen. In practice, from your description, it sounds like memory reserved for c happens to have byte value 0, which is unprintable character, so printf prints something else (maybe /0, maybe nothing). And then the environment (vim) might show you the program exit code, also 0 here (assuming the Undefined Behavior doesn' cause your program to crash).
To fix this, check return value of scanf:
#include<stdio.h>
int main()
{
char c ;
int r = scanf(" %c",&c);
if (r==1) {
// Always print something and add newline
// to be sure we see some output always.
printf("c='%c'\n",c);
} else {
printf("scanf error: %d\n", r);
// If r==-1, errno variable tells what error was
}
return 0;
}
Practical hint: To provide standard input when there is no terminal (so you can't type the input), you can pipe something:
echo A | ./thisprogram
I've tried to run your program (exactly as it appears in your question)
pru.c
#include<stdio.h>
int main()
{
char c ;
scanf(" %c",&c);
printf("%c",c);
return 0;
}
and with the input you posted in your question (just A plus Enter) and got the following result:
$ cc pru.c
$ ./a.out
A
A$ _
which is exactly the expected output. So the problem must be in another place, or you have a completely different scenario and need to provide more information.
I tested this on a PC (Intel Core Duo) with FreeBSD 12.0/CLANG compiler. (here $ is the unix prompt and _ is the cursor after the run) And of course, the program has been edited with vi(1) (this has no impact on the result).
Edit
Try to change
printf("%c",c);
by this
printf("0x%02x, [%c]\n",c,c);
so, you'll get an hex dump of the character just input, and also its representation as printed. The \n at the end is to ensure your shell prompt is not eating (overwriting) the last line output of your program (mostly if you have changed the prompt variable PS1) hidding the printed char.
That should produce (on your posted input) the following output:
$ cc pru.c <--- compilation of new pru.c
$ ./a.out <--- default name for your program executable.
A <--- this is your input (followed by <return>)
0x41, [A] <--- this should be your program output.
$ _ <--- prompt (and cursor) after your program execution
I'm currently in the very early stages of learning C programming and am working my way through "Beginning Programming with C for Dummies" using Code::Blocks.
The first activity in Chapter 7, Fetching characters with getchar(), asks us to copy the code exactly as it's presented in the book; see below:
#include <stdio.h>
int main()
{
int c;
printf("I'm waiting for a character: ");
c = getchar();
printf("I waited for the '%c' character.\n", c);
return (0);
}
The output I get is:
I'm waiting for a character:
However according to the book, the output that I should be seeing is the character's ASCII code value. It then asks that I change the %c placeholder to %d to display the value, but still I get the same outcome as before. I could probably recite the code with my eyes closed I've checked it through that may times; I simply cannot see where I'm going wrong.
Am I right in thinking that the getchar() function isn't being recognized? Or that the code isn't being read after the first printf statement? Any guidance is welcome as I don't want to move on until I've understood the problem.
Please enter any key, then 2nd printf will show the result. getchar() is expecting input from user, controller reach at 2nd line & waiting for input.
I am new to Xcode development tool. To debug a problem, I have tried a very simple code:
int main()
{char N;
char M;
scanf("%c",&N);
scanf("%c",&M);
printf("%c",N);
printf("%c",M);
}
But the problem is that the compiler doesn't seem to read the second scanf. So I can enter one character in the console, and then the program stops. Amazingly, when I write the same code with "int" in place of "char", it works just fine. Does anybody have an idea what's wrong?
You're pressing Enter after typing a character into the first scanf, right? That Enter is what gets read by the second scanf. And printed by the second printf.
You haven't shown the output of this program, but if you change the printf formatting to %d\n from %c, then it's probably something like the following if you type "a" and press Enter:
97
10
That 10 is the character code for Enter (newline or line feed).
Ok I'm just learning C and stumble upon this practice code to count character K&R's book:
#include <stdio.h>
/* count characters in input; 2nd version */
main()
{
double nc;
for (nc = 0; getchar() != EOF; ++nc)
;
printf("%.0f\n", nc);
}
The problem is I don't know whether is it suppose to print the amount of characters or not when I entered any character because there is no output whatsoever, just whitespace (getchar() waiting for another input).
Can someone explain to me what is going on? I'm practicing in bash using vim in openSUSE 11.3.
You have to send the EOF signal/character to the program. If you are running it from inside a terminal window, press Ctrl+D.
If you are piping from a file, like so:
./my_program < input_file_name
then it will work automagically.
Since it is checking for EOF, hit Ctrl-D in the terminal.
As others have mentioned, you have to press control-d (aka ^d) but that only works after you hit return. In other words you cannot type "foocontrol-d" and expect it to work. "fooreturncontrol-d" would work, though.
Also please note that K&R is a fine fine book, but was written decades ago. The counting algorithm presented only work on ASCII-ish input. Wide characters (UTF-8, etc) would not be counted correctly.
Also also note, the example you quoted is using a floating point number for this counting. There is little strictly wrong with this, but for speed and efficiency, most people would use unsigned ints, longs, or some other intergral datatype. You are not likely to be reading ¾th of a character!