K&R2 section 1.5.1 - "getchar" problem

[arnuld]

i have slightly modified the programme from section 1.5.1 which takes
the input frm keyboard and then prints that to the terminal. it just
does not run and i am unable to understand the error message.

may you tell me what is wrong and how to make that right ?

------------------------------ INPUT ---------------------
#include <stdio.h>

int main() {
int c;

while((c = getchar()) != EOF)
{
printf("your input: ");
putchar(c);
printf("\n");
}

return 0;
}

--------------------- OUTPUT -----------------------------
[arch@voodo kr2]$ gcc -ansi -pedantic -Wall -Wextra 151.c
151.c:1: error: expected identifier or '(' before '/' token
151.c:2:12: error: too many decimal points in number
In file included from /usr/include/_G_config.h:44,
from /usr/include/libio.h:32,
from /usr/include/stdio.h:72,
from 151.c:4:
/usr/include/gconv.h:72: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/gconv.h:88: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/gconv.h:97: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/gconv.h:174: error: expected specifier-qualifier-list
before 'size_t'
In file included from /usr/include/stdio.h:72,
from 151.c:4:
/usr/include/libio.h:328: error: expected specifier-qualifier-list
before 'size_t'
/usr/include/libio.h:360: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/libio.h:369: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/libio.h:485: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '_IO_sgetn'
In file included from 151.c:4:
/usr/include/stdio.h:306: error: expected declaration specifiers or
'...' before 'size_t'
/usr/include/stdio.h:608: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'fread'
/usr/include/stdio.h:614: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'fwrite'
[arch@voodo kr2]$

[santosh]

arnuld wrote:

On Mar 8, 12:17 pm, Keith Thompson <[e-mail] ote:

The only thing I can think of is that your source file originally
contained some funny characters.

yes, it did contain some *funny* characters. actually they were at the
beginning of programme. they look like:

// K&R2 section 1.5.1
//

i was writing C++ in C

Impossible. You were trying to feed the compiler C99 features while
telling it to stick to strict C89.

[ ... ]

[arch@voodo kr2]$ ./a.out
a
your input: a
your input:

b
your input: b
your input:

[arch@voodo kr2]$

why i am getting "your input" 2 times, instead of one ?

Let me guess. You typed a letter 'a', then hit the return key.
That's two characters.

NO, i am not talking about characters. i am talking about "words":
your input

after getchar(), there must be one sentence:

"your input: a"
but i get 2 sentences. 2nd one is:

"your input: "
why so ? (when i have used it once only in programme)

When you type in normal characters through the keyboard, under line
buffered systems, (which happens to be almost all operating systems),
you need to press the Return or Enter key to signal that your input
can be processed. The Enter key also generates a perfectly ordinary
value, (or values), like all other keys do. So your program is
actually receiving the value of 'a' followed by the value for '\n',
(which is C's representation of the system's end-of-line sequence,
which is itself generated by pressing the Return or Enter key.)

Both key values, ('a' and '\n'), are stored into the C library's
internal buffer for stdin stream. getchar goes and retrieves the top
character of the buffer, ('a'), and your loop prints it, followed by
your newline. The next iteration of loop calls getchar once again. You
_meant_ it to block for fresh input from the keyboard. But the '\n' is
still sitting in the internal buffer, and in C, it's a perfectly valid
character, which getchar retrieves and you print once again, as a
seemingly empty statement, but if you observe closely, you'll spot an
extra blank line. That's the effect of printing the '\n' character.

This "issue" confuses many a newbie. Sometimes this behaviour of the
stdio functions is expected, sometimes it's an annoyance. If you don't
want this behaviour you'll have to "read" and discard the remaining
characters in the internal buffer uptil, and including, the next
newline. You can do it through a simple while loop and wrap it up in a
function named, say, consume_line or something.

[arnuld]

On Mar 8, 4:53 pm, "santosh" <santosh....@gm ail.comwrote:

// K&R2 section 1.5.1
//

i was writing C++ in C

Impossible. You were trying to feed the compiler C99 features while
telling it to stick to strict C89.

which one is a good practice: C99 or C89 ?

if it is C99 then just tell what options of "gcc" on Linux make it C99
compliant.

When you type in normal characters through the keyboard, under line
buffered systems, (which happens to be almost all operating systems),
you need to press the Return or Enter key to signal that your input
can be processed. The Enter key also generates a perfectly ordinary
value, (or values), like all other keys do. So your program is
actually receiving the value of 'a' followed by the value for '\n',
(which is C's representation of the system's end-of-line sequence,
which is itself generated by pressing the Return or Enter key.)

Both key values, ('a' and '\n'), are stored into the C library's
internal buffer for stdin stream. getchar goes and retrieves the top
character of the buffer, ('a'), and your loop prints it, followed by
your newline. The next iteration of loop calls getchar once again. You
_meant_ it to block for fresh input from the keyboard. But the '\n' is
still sitting in the internal buffer, and in C, it's a perfectly valid
character, which getchar retrieves and you print once again, as a
seemingly empty statement, but if you observe closely, you'll spot an
extra blank line. That's the effect of printing the '\n' character.

This "issue" confuses many a newbie. Sometimes this behaviour of the
stdio functions is expected, sometimes it's an annoyance. If you don't
want this behaviour you'll have to "read" and discard the remaining
characters in the internal buffer uptil, and including, the next
newline. You can do it through a simple while loop and wrap it up in a
function named, say, consume_line or something.

thanks for the pretty long explanation

:-)

[santosh]

arnuld wrote:

On Mar 8, 4:53 pm, "santosh" <santosh....@gm ail.comwrote:

// K&R2 section 1.5.1
//

i was writing C++ in C

Impossible. You were trying to feed the compiler C99 features while
telling it to stick to strict C89.

which one is a good practice: C99 or C89 ?

Anyone. The core language hasn't changed all that much. The constructs
that've been added are not likely to be used at a beginner level. If
your compiler and standard library has acceptable amount of C99
coverage, and you're aware of the possibility of your code not working
with other implementations , then there's nothing wrong in learning C99
features. It is, after all, the current Standard for C.

if it is C99 then just tell what options of "gcc" on Linux make it C99
compliant.

First off gcc isn't yet fully C99 compliant, though it's getting there
faster than some other compilers.

The -std=c99 and -pedantic options can be used. Also you might want to
always use the -Wall and -Wextra options for maximum diagnostic
output. The manual for gcc has lots of interesting information you can
use to tailor gcc's behaviour for your use. Invoke 'info gcc'.

[arnuld]

On Mar 8, 10:27 pm, "santosh" <santosh....@gm ail.comwrote:

which one is a good practice: C99 or C89 ?

Anyone. The core language hasn't changed all that much. The constructs
that've been added are not likely to be used at a beginner level. If
your compiler and standard library has acceptable amount of C99
coverage, and you're aware of the possibility of your code not working
with other implementations , then there's nothing wrong in learning C99
features. It is, after all, the current Standard for C.

if it is C99 then just tell what options of "gcc" on Linux make it C99
compliant.

First off gcc isn't yet fully C99 compliant, though it's getting there
faster than some other compilers.

i did not know that.

The -std=c99 and -pedantic options can be used. Also you might want to
always use the -Wall and -Wextra options for maximum diagnostic
output. The manual for gcc has lots of interesting information you can
use to tailor gcc's behaviour for your use. Invoke 'info gcc'.

thanks buddy

;-)

[Beej Jorgensen]

arnuld <ge*********@gm ail.comwrote:

>which one is a good practice: C99 or C89 ?

C99 isn't entirely widespread yet, so that might be a problem for
portability. Personally, I don't shy away from it.

You should at least know about the new features in C99 so you don't end
up doing things like this:

int restrict = 1;

>if it is C99 then just tell what options of "gcc" on Linux make it C99
compliant.

http://gcc.gnu.org/onlinedocs/gcc-4....t-Options.html

Check out "-std=".

gcc isn't fully compliant yet. Here's a link with the details:

http://gcc.gnu.org/gcc-4.1/c99status.html

-Beej