Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #17128 > unrolled thread

K&R p.97

Back to article view | Back to comp.lang.c

Contents

  K&R p.97 Tom <t.scrace@gmail.com> - 2012-02-11 12:46 -0800
    Re: K&R p.97 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-11 13:25 -0800
    Re: K&R p.97 Ian Collins <ian-news@hotmail.com> - 2012-02-12 10:36 +1300
      Re: K&R p.97 Tom <t.scrace@gmail.com> - 2012-02-11 14:18 -0800
        Re: K&R p.97 Ian Collins <ian-news@hotmail.com> - 2012-02-12 11:38 +1300
          Re: K&R p.97 Tom <t.scrace@gmail.com> - 2012-02-11 14:44 -0800
            Re: K&R p.97 Ian Collins <ian-news@hotmail.com> - 2012-02-12 14:34 +1300
        Re: K&R p.97 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 22:52 +0000
    Re: K&R p.97 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 17:09 -0500

#17128 — K&R p.97

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

[toc] | [next] | [standalone]

#17131

On Feb 11, 8:46 pm, Tom <t.scr...@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#17133

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

[toc] | [prev] | [next] | [standalone]

#17138

On Feb 11, 9:36 pm, Ian Collins <ian-n...@hotmail.com> 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

[toc] | [prev] | [next] | [standalone]

#17145

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

[toc] | [prev] | [next] | [standalone]

#17147

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

[toc] | [prev] | [next] | [standalone]

#17164

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

[toc] | [prev] | [next] | [standalone]

#17149

Tom <t.scrace@gmail.com> writes:

> On Feb 11, 9:36 pm, Ian Collins <ian-n...@hotmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#17136

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
esosman@ieee-dot-org.invalid

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web