LinuxQuestions.org - Can't make a simple C program work..

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - Can't make a simple C program work.. (https://www.linuxquestions.org/questions/programming-9/cant-make-a-simple-c-program-work-4175506966/)

Can't make a simple C program work..

Hello all,

I'm reading the K&R C for the first time(meaning, I went went through it w/o too much attention, but this time I aim to actually finish it..)

Though I'm not a *NIX newbie, I am at a loss, I cannot make even this simple program work.
"Exercise 1-8. Write a program to count blanks, tabs, and newlines." , Okay, so I just started with counting the tabs, aiming low.
The program behaves erratically, at times it will print "hello", and at times, not : - regardless of if a TAB char was actually entered.
I tried all sorts of combinations for the if() statement, but, none worked for me.
I read about printf() as much a I could, but, still, cannot figure out exactly how it behaves.
Thank you in advance for your input.

Code:

#include <stdio.h>



main()

{



char t;

t=getchar();

        while(t != EOF)

        {

                if( t == '\t' && '\n')

                {

                printf("hello");

                t=getchar();

                }



        }

}

Hi,

I think the main problem here is that you need to call t=getchar(), every iteration of the loop, not just if the if statement succeeds.

Evo2.

Quote:

Originally Posted by evo2 (Post 5181970)

Hi,

I think the main problem here is that you need to call t=getchar(), every iteration of the loop, not just if the if statement succeeds.

Evo2.

Thank you Evo2!
That did it. I carried the placement of the t=getchar() from a previous program, and did not pay any attention to its location, only messed with the if() statement, which proved to be a mistake.

That if statement looks wrong. Firstly, you're testing whether "\n" is true (i.e. on the right-hand side of your and operation). That's likely not what you want - you probably meant t == "\n". Secondly, since a character can't be both a tab and a new line, that test would always fail. You probably meant to check whether one or the other was true (i.e. t == "\t" || t == "\n").

You mean: t=='\t' || t=='\n'

Note: 't' should be an 'int' not a 'char', otherwise character '\xff' will be treated as EOF (or vice versa, depending of signedness of 'char' type)

Quote:

Originally Posted by NevemTeve (Post 5182063)

You mean: t=='\t' || t=='\n'

Note: 't' should be an 'int' not a 'char', otherwise character '\xff' will be treated as EOF (or vice versa, depending of signedness of 'char' type)

I see,
Thank you.
BTW, does getchar() hold only one char at a time ? or can it hold a string, as well ?

Quote:

Originally Posted by G_A (Post 5182137)

BTW, does getchar() hold only one char at a time ? or can it hold a string, as well ?

The name of the function tells you all you need to know - getchar() returns only a single character.

Move the t=getchar() into the while loop and get rid of the one in the if()
Keep in mind getchar() is (annoyingly) buffered which means if your input source is the keyboard, then it will not recognize the input unless you hit enter or type a whole lot

Other's have pointed out the errors in the original IF statement. That's really the biggest one.

Suggestions are that you find ways to get information about each library call and understand what range of behaviors to expect from them; those being: getchar(), and printf(). I find the linux.die.net manual pages to be very common ones I encounter when I search for thing like "getchar man page". However also, you can just type:

Code:

man getchar

in your Linux terminal a.k.a. Linux command prompt.

What you'll notice is the following:

getchar() requires stdio.h
getchar() returns an int however it "interprets" whatever it read as an unsigned char and casts that to an int in order to return it to the calling function
getchar() does read from stdin and is the equivalent of getc(stdin)
getchar() will return EOF at end of file or on error

What I don't see in either the online variation or my local man page is what possible ERRNO values you could encounter if getchar() did encounter an error; however a number of other library calls will indicate possible ERRNO values and their meaning.

printf() is pretty encompassing, as is scanf() therefore I suggest experimentation as well as investigation about the behavior of the function. Further, you could use printf() to output the value of "t" just after you take it in via getchar()

Code:

t = getchar();

printf("Character was: %d(%#02x)\n", t, t);

What does that do for you? It prints out the character as it was typed, and if it was carriage return, newline, or backspace then you'll see much of nothing; however it next prints out the character in HEX, the # makes it use "0x" to lead it off, the "02" makes it always a 2-digit printout; those are merely my preferences when printing an ASCII character in HEX. You can check the character with an ASCII table, like An ASCII Online Reference I use. Following this technique and doing excessive output as your program progresses will give you insight as to what you may have done wrong, misunderstood, or just general information to validate that steps are working as you expected they would. I think what you may be seeing is that there are a number of possible things you could type which affect that program's operation. Like if you type ESCAPE, SPACE, ENTER, CTRL-B, and so forth.

Other suggestions, especially if you're using C in the Linux command line and learning C programming is to learn how to use GDB and learn compile options for GCC.

GDB is the GNU debugger and you can basically use that to run your program, set a breakpoint, step through your program and examine data as it changes. It's very helpful, especially as your programming sophistication grows.

GCC is the compiler and there are plenty of options to consider when you compile a program; maybe even consider creating a Makefile so that you don't have to type lengthy arguments all the time. What I'm talking about here are enabling switches in your compile to detect warnings, such as -Wall. If you look at GCC you'll see that there's a lot included as well as a lot not included in the -Wall switch. I continually grow my list of compiler switches and look to have no warnings in my compilations. Warnings are an indication that you've gone slightly, or fully out of bounds or scope for acceptable programming; heed them. But note that if you don't put in any switches to your compile, then you'll see very few real compile complaints excepting severe errors.