Velocity Reviews > K&R p.97

# K&R p.97

Tom
Guest
Posts: n/a

 02-11-2012
Guys,

On page 97 of K&R (2nd ed) there is a function called getint().

I won't paste it here because I assume most people can look it up, but
if you want me to I will.

The 6th line of the body of the function is:

ungetch(c) /* it's not a number */

I don't understand this. This pushes the character (c) back to input
if it is not a number. But this creates an infinite cycle of finding a
non-number, pushing it back to input, reading the next character on
the input, finding it to be the same non-digit character and pushing
it back again.

Shouldn't this line be omitted, so that we can just skip to 'return
0', so that we can progress to the next character in the input?

As the function is written, if we hit a non-digit in the input it will
just get stuck there until the algorithm hits the MAX limit.

Am I missing something or is this a mistake?

Thanks,

Tom

Malcolm McLean
Guest
Posts: n/a

 02-11-2012
On Feb 11, 8:46*pm, Tom <(E-Mail Removed)> wrote:
>
> The 6th line of the body of the function is:
>
> ungetch(c) /* it's not a number */
>
> I don't understand this. This pushes the character (c) back to input
> if it is not a number. But this creates an infinite cycle of finding a
> non-number, pushing it back to input, reading the next character on
> the input, finding it to be the same non-digit character and pushing
> it back again.
>

I haven't a copy of the book.
It's possible that you've found a bug in the K and R example, but it's
unlikely. ungetc() (it should be ungetc, not ungetch) puts the last
character read back into the input stream. It's quite commonly used
when a parser reads to the end of the input it understands. The last
character after a number is a non-digit, so it knows the integer is
finished, but it can't understand what that character is doing. So it
puts it back to enable higher level code to decide what to do.
--
Vist my website, lots of free games to play
http://www.malcolmmclean.site11.com/wwww

Ian Collins
Guest
Posts: n/a

 02-11-2012
On 02/12/12 09:46 AM, Tom wrote:
> Guys,
>
> On page 97 of K&R (2nd ed) there is a function called getint().
>
> I won't paste it here because I assume most people can look it up, but
> if you want me to I will.
>
> The 6th line of the body of the function is:
>
> ungetch(c) /* it's not a number */

Followed by a return. This function has done its job (extracting an
integer from the stream) so it has to push the last character it read
back into the stream. If it didn't, that character would be lost.

--
Ian Collins

Eric Sosman
Guest
Posts: n/a

 02-11-2012
On 2/11/2012 3:46 PM, Tom wrote:
> Guys,
>
> On page 97 of K&R (2nd ed) there is a function called getint().
>
> I won't paste it here because I assume most people can look it up, but
> if you want me to I will.
>
> The 6th line of the body of the function is:
>
> ungetch(c) /* it's not a number */
>
> I don't understand this. This pushes the character (c) back to input
> if it is not a number. But this creates an infinite cycle of finding a
> non-number, pushing it back to input, reading the next character on
> the input, finding it to be the same non-digit character and pushing
> it back again.

If you call the same function again without doing anything else,
it will behave as you say. Presumably, though, after you've read
a number and swallowed all the input up to a non-number, your next
action would be to read and do something non-numeric with the non-
number. For example, if the input file looks like

1+(2-3)*5

.... you'd probably want to examine and do something with the
interstitial characters, not just ignore them without even
knowing what they were.

> Shouldn't this line be omitted, so that we can just skip to 'return
> 0', so that we can progress to the next character in the input?

You'll process the next character(s) in some other way. There's
a stream of numbers and non-numbers; both components are meaningful.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d

Tom
Guest
Posts: n/a

 02-11-2012
On Feb 11, 9:36*pm, Ian Collins <(E-Mail Removed)> wrote:

> Followed by a return. *This function has done its job (extracting an
> integer from the stream) so it has to push the last character it read
> back into the stream. *If it didn't, that character would be lost.
>
> --
> Ian Collins

Yes, I see your point. Thank you.

However, if the function is called using the for loop on p.96 then we
will see the behaviour I described, won't we?

The code that calls the function should account for a non-numerical
character, but it seems like the code on p.96 does not.

Is this right?

Thanks again,
Tom

Ian Collins
Guest
Posts: n/a

 02-11-2012
On 02/12/12 11:18 AM, Tom wrote:
> On Feb 11, 9:36 pm, Ian Collins<(E-Mail Removed)> wrote:
>
>> Followed by a return. This function has done its job (extracting an
>> integer from the stream) so it has to push the last character it read
>> back into the stream. If it didn't, that character would be lost.

> Yes, I see your point. Thank you.
>
> However, if the function is called using the for loop on p.96 then we
> will see the behaviour I described, won't we?

There isn't a loop on that page. But yes, if you where to blindly call
the function without checking the result you would be in a loop.

> The code that calls the function should account for a non-numerical
> character, but it seems like the code on p.96 does not.

The code is nothing more than a function to read an integer. Whatever
calls it determines what to do next.

--
Ian Collins

Tom
Guest
Posts: n/a

 02-11-2012
On Feb 11, 10:38*pm, Ian Collins <(E-Mail Removed)> wrote:
> On 02/12/12 11:18 AM, Tom wrote:
>
> > On Feb 11, 9:36 pm, Ian Collins<(E-Mail Removed)> *wrote:

>
> >> Followed by a return. *This function has done its job (extracting an
> >> integer from the stream) so it has to push the last character it read
> >> back into the stream. *If it didn't, that character would be lost.

> > Yes, I see your point. Thank you.

>
> > However, if the function is called using the for loop on p.96 then we
> > will see the behaviour I described, won't we?

>
> There isn't a loop on that page. *But yes, if you where to blindly call
> the function without checking the result you would be in a loop.

Maybe we have different versions of the book. In my version there is
the following on page 96:

for (n = 0; n < SIZE && getint(&array[n]) != EOF; n++)
;

Ben Bacarisse
Guest
Posts: n/a

 02-11-2012
Tom <(E-Mail Removed)> writes:

> On Feb 11, 9:36Â*pm, Ian Collins <(E-Mail Removed)> wrote:
>
>> Followed by a return. Â*This function has done its job (extracting an
>> integer from the stream) so it has to push the last character it read
>> back into the stream. Â*If it didn't, that character would be lost.
>>
>> --
>> Ian Collins

>
> Yes, I see your point. Thank you.
>
> However, if the function is called using the for loop on p.96 then we
> will see the behaviour I described, won't we?
>
> The code that calls the function should account for a non-numerical
> character, but it seems like the code on p.96 does not.
>
> Is this right?

I, for one, would have to see the loop and getint function to be sure.
However, the code in my 1st edition version will get "stuck" on
non-numeric input, but the for loop on the previous page won't loop
indefinitely because it is also bounded by the array size. Hence an
input stream of, say,

1-2 45x 99

will read 1, -2, 45 and then fill the rest of the array with zeros,
leaving the x unread. It's maybe not ideal, but it's a reasonable way
to handle unintelligible input.

--
Ben.

Ian Collins
Guest
Posts: n/a

 02-12-2012
On 02/12/12 11:44 AM, Tom wrote:
> On Feb 11, 10:38 pm, Ian Collins<(E-Mail Removed)> wrote:
>> On 02/12/12 11:18 AM, Tom wrote:
>>
>>> On Feb 11, 9:36 pm, Ian Collins<(E-Mail Removed)> wrote:

>>
>>>> Followed by a return. This function has done its job (extracting an
>>>> integer from the stream) so it has to push the last character it read
>>>> back into the stream. If it didn't, that character would be lost.
>>> Yes, I see your point. Thank you.

>>
>>> However, if the function is called using the for loop on p.96 then we
>>> will see the behaviour I described, won't we?

>>
>> There isn't a loop on that page. But yes, if you where to blindly call
>> the function without checking the result you would be in a loop.

>
> Maybe we have different versions of the book. In my version there is
> the following on page 96:
>
> for (n = 0; n< SIZE&& getint(&array[n]) != EOF; n++)
> ;

I do have two versions of the book, the one with my glasses on and the
one with my glasses off!

The loop will fill the array with zeros if the input isn't numeric. The
loop is bound by the array size.

--
Ian Collins