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...(probably 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...(probably 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...(probably 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...(probably 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...although 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*****@invalid.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...(probably 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...incredibly helpful.

[mdh]

Richard Heathfield wrote:

As I have already explained, K&R only expect you to provide digits in your
test data.

A quick question for Richard.
The first exercise after this small example given by K&R, asks the
reader to "fix" the example so that a "+" or a "-" NOT followed by a
digit is correctly pushed back to the input. K&R seem to imply that the
input might not only be digits. Up to now, I have found all their
examples to be spot on with no ambiguity...perhaps this is the first
one?

[santosh]

mdh wrote:

Richard Heathfield wrote:

As I have already explained, K&R only expect you to provide digits in your
test data.

A quick question for Richard.
The first exercise after this small example given by K&R, asks the
reader to "fix" the example so that a "+" or a "-" NOT followed by a
digit is correctly pushed back to the input. K&R seem to imply that the
input might not only be digits. Up to now, I have found all their
examples to be spot on with no ambiguity...perhaps this is the first
one?

I don't see any ambiguity. Their example omits rigorous error checking
for the sake of brevity, (as the authors themselves explain once or
twice in the book), but the exercises are meant to help you think by
often asking _you_ to extend their examples. Here, they're asking you
to incorporate rudimentary input checking and take appropriate action
upon encountering unexpected input.

[mdh]

santosh wrote:

I don't see any ambiguity. ........

>....... Here, they're asking you
to incorporate rudimentary input checking and take appropriate action
upon encountering unexpected input.

Ok...the difference is that when you guys ( the experienced ones :-) )
look at the issue, it is obvious what they are saying. When one is
learning it, one often wonders what one is missing!
I guess that's what makes this list so helpful.
Your input is appreciated...thanks.

[santosh]

mdh wrote:

santosh wrote:

I don't see any ambiguity. ........

....... Here, they're asking you
to incorporate rudimentary input checking and take appropriate action
upon encountering unexpected input.

Ok...the difference is that when you guys ( the experienced ones :-) )
look at the issue, it is obvious what they are saying. When one is
learning it, one often wonders what one is missing!
I guess that's what makes this list so helpful.
Your input is appreciated...thanks.

If increasing distance from the Sun were directly proportional to
experience with C, then probably you'd be Proxima Centauri, I'd be
Alpha Centauri while Richard might be Deneb. :)

[mdh]

santosh wrote:

If increasing distance from the Sun were directly proportional to
experience with C, then probably you'd be Proxima Centauri, I'd be
Alpha Centauri while Richard might be Deneb. :)

LOL...PLEASE let it take less than 4.22 years for some of the light of
C to reach me!!!

[Richard Heathfield]

mdh said:

>
Richard Heathfield wrote:

>As I have already explained, K&R only expect you to provide digits in
your test data.

A quick question for Richard.
The first exercise after this small example given by K&R, asks the
reader to "fix" the example so that a "+" or a "-" NOT followed by a
digit is correctly pushed back to the input. K&R seem to imply that the
input might not only be digits. Up to now, I have found all their
examples to be spot on with no ambiguity...perhaps this is the first
one?

You appear to have missed Exercise 5-1A, which reads:

"By now, you've probably discovered other ways to confuse the code. Fix it."
:-)

--
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.