question about an exercise in K&R (p96)

[mdh]

I am just trying to figure out if this is intended behavior, or whether
I am missing something...(pr obably the latter).

The example given (p96, K&R) is meant to illustrate pointer behavior.

K&R say the example "break(s) a stream of characters into integer
values"

The relevant code is: ( I think)

(in Main)

for (i=0; i < SIZE && getint(&arr[i]) != EOF; i++);

and I believe the relevent code in getint is:

while ( isspace(c=getch ()));

if ( !isdigit (c) && c != EOF && c != '+' && c != '-'){
ungetch(c);
return 0;

where getch() and ungetch() are K&R versions of pushing/getting the
extra character to/from a buffer.
My question is this:

If my input is something like: " 89 76 45 -90" the out put is the same
(if I print the array)

but as soon as I introduce a character other than a digit, it goes into
an endless loop, and exits when

i < SIZE is false.

Is this the intended behavior?

Thanks in advance.

[Richard Heathfield]

mdh said:

I am just trying to figure out if this is intended behavior, or whether
I am missing something...(pr obably the latter).

The example given (p96, K&R) is meant to illustrate pointer behavior.

<snip>

but as soon as I introduce a character other than a digit, it goes into
an endless loop, and exits when

i < SIZE is false.

Is this the intended behavior?

It's not the intended input, that's for sure! Either K&R are sacrificing
robustness for clarity (which, in my view, is a mistake, but that's a
matter of opinion) - or they screwed up. Your call.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[santosh]

Richard Heathfield wrote:

mdh said:

I am just trying to figure out if this is intended behavior, or whether
I am missing something...(pr obably the latter).

The example given (p96, K&R) is meant to illustrate pointer behavior.

<snip>

but as soon as I introduce a character other than a digit, it goes into
an endless loop, and exits when

i < SIZE is false.

Is this the intended behavior?

It's not the intended input, that's for sure! Either K&R are sacrificing
robustness for clarity (which, in my view, is a mistake, but that's a
matter of opinion) - or they screwed up. Your call.

One would've thought a bug in K&R's exercises would've been spotted
before now. It would help if mdh posted the full source, as my copy of
K&R isn't at hand right now.

[Richard Heathfield]

santosh said:

Richard Heathfield wrote:

>mdh said:

I am just trying to figure out if this is intended behavior, or whether
I am missing something...(pr obably the latter).

The example given (p96, K&R) is meant to illustrate pointer behavior.

<snip>

but as soon as I introduce a character other than a digit, it goes into
an endless loop, and exits when

i < SIZE is false.

Is this the intended behavior?

It's not the intended input, that's for sure! Either K&R are sacrificing
robustness for clarity (which, in my view, is a mistake, but that's a
matter of opinion) - or they screwed up. Your call.

One would've thought a bug in K&R's exercises would've been spotted
before now.

It isn't a bug as such. The program works fine when presented with
appropriate input, and this is, after all, an exercise in pointers as
function arguments! K&R may well have considered a more robust driver to be
a distraction. In fact, they don't even bother to present a complete
driver. The code the OP as quoted as being from main() is in fact just a
four-line code fragment.

It would help if mdh posted the full source,

What he posted, pretty much, is all the code they wrote for this, although
he appears to have done it from memory, as there are one or two
discrepancies.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[mdh]

Richard Heathfield wrote:

>

It would help if mdh posted the full source,

What he posted, pretty much, is all the code they wrote for this, although
he appears to have done it from memory, as there are one or two
discrepancies.

Well, that is what I wondered...alth ough I have looked over it again
and again. Here is the full code...somewhat altered, mainly so I could
understand it.

>>>>>>>>>>>>

#include <stdio.h>
# define SIZE 10

int main (){

int getint( int *ptr );
int arr[SIZE], i;

printf("Write a sentence with a bunch of numbers:\n\n");

for (i=0; i < SIZE && getint(&arr[i]) != EOF; i++);

printf("\nThe following numbers were scanned\n\n");

for (--i; i >= 0; i--)
printf( "%d \n", arr[i] );

return 0;
}
/*******int getint( int *arr ) ******/
#include <ctype.h>
int getint( int *ptr ){

void ungetch( int );
int getch(void);

int sign, c;

while ( isspace(c=getch ())); /**ignores white spaces ****/

/** now filter for a number **/

if ( !isdigit (c) && c != EOF && c != '+' && c != '-'){
ungetch(c);
return 0;
} /** this is not a number **/

/*** filtered for EOF, +, -, number ***/
sign = (c=='-')? -1: 1;
if (c=='+' || c == '-')
c=getch();

for ( *ptr=0; isdigit(c); c=getch())
*ptr=10* *ptr + ( c-'0');

*ptr *= sign;
if ( c != EOF)
ungetch(c);
return c;
}
/*******void ungetch( int )******/
/******int getch(void)**** **/

#define SIZE2 50
int buffer[SIZE2], buffpos=0;

void ungetch( int c ){

if ( buffpos >= SIZE2)

printf ( "Error: Buffer Overflow");

else

buffer[buffpos++]=c;

}

int getch(void){

return (buffpos 0) ? buffer[--buffpos]: getchar() ;

}

<<<<<<<<<<<<

[mdh]

mdh wrote:
Here is the full code:

Here is some input/output I obtained:

>>>>>

Write a sentence with a bunch of numbers:

34 67 -90


The following numbers were scanned

-90
67
34

ptrs has exited with status 0. <<=== Seems to work ok if input is
ONLY digits

<<<<<<<<<

Write a sentence with a bunch of numbers:

run 89

The following numbers were scanned

0
0
0
1
0
-1881117246
1
0
2036621151
115

ptrs has exited with status 0. <<<== Not quite sure what is going on
here...hence my post.

<<<<<<<<<<<<

[Richard Heathfield]

mdh said:

>
Seems to work ok if input is ONLY digits

As I have already explained, K&R only expect you to provide digits in your
test data. Their emphasis here is on learning how to use pointers to tell
functions where arrays live. They have skimped (wrongly, in my view, but
that's a matter of opinion) on error-checking in their skeleton driver.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[mdh]

Richard Heathfield wrote:

mdh said:

Seems to work ok if input is ONLY digits

As I have already explained, K&R ..........

Just wanted to make sure. Thank you for your input...it is always
appreciated.

[Tim Hagan]

"Richard Heathfield" <in*****@invali d.invalidwrote in message
news:tP******** ************@bt .com...

mdh said:

>I am just trying to figure out if this is intended behavior, or whether
I am missing something...(pr obably the latter).

The example given (p96, K&R) is meant to illustrate pointer behavior.

<snip>

>but as soon as I introduce a character other than a digit, it goes into
an endless loop, and exits when

i < SIZE is false.

Is this the intended behavior?

It's not the intended input, that's for sure! Either K&R are sacrificing
robustness for clarity (which, in my view, is a mistake, but that's a
matter of opinion) - or they screwed up. Your call.

That's what I thought a few years back:

http://groups.google.com/group/comp....c19714cdd8795d

Conclusion: "It's just the example program that could be more robust."

--
Tim Hagan

[mdh]

Tim Hagan wrote:

>
That's what I thought a few years back:

Good to know that the same confusion existed before!!! :-)
I still love K&R. Best of the books I have read. Plus, this group is
great...incredi bly helpful.