# K&R p.97

Discussion in 'C Programming' started by Tom, Feb 11, 2012.

1. ### TomGuest

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

Tom, Feb 11, 2012

2. ### Malcolm McLeanGuest

On Feb 11, 8:46 pm, Tom <> 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

Malcolm McLean, Feb 11, 2012

3. ### Ian CollinsGuest

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

Ian Collins, Feb 11, 2012
4. ### Eric SosmanGuest

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
d

Eric Sosman, Feb 11, 2012
5. ### TomGuest

On Feb 11, 9:36 pm, Ian Collins <> 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

Tom, Feb 11, 2012
6. ### Ian CollinsGuest

On 02/12/12 11:18 AM, Tom wrote:
> On Feb 11, 9:36 pm, Ian Collins<> 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

Ian Collins, Feb 11, 2012
7. ### TomGuest

On Feb 11, 10:38 pm, Ian Collins <> wrote:
> On 02/12/12 11:18 AM, Tom wrote:
>
> > On Feb 11, 9:36 pm, Ian Collins<>  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++)
;

Tom, Feb 11, 2012
8. ### Ben BacarisseGuest

Tom <> writes:

> On Feb 11, 9:36Â pm, Ian Collins <> 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.

Ben Bacarisse, Feb 11, 2012
9. ### Ian CollinsGuest

On 02/12/12 11:44 AM, Tom wrote:
> On Feb 11, 10:38 pm, Ian Collins<> wrote:
>> On 02/12/12 11:18 AM, Tom wrote:
>>
>>> On Feb 11, 9:36 pm, Ian Collins<> 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

Ian Collins, Feb 12, 2012