Thread: K&R Ch4 Polish calculator, two questions

Originally Posted by CommonTater

Check your compiler docs... you may be on a compiler or OS version that only supports single characters for ungetch().
This is from the Pelles C, help file...


Note that this is an older function, now branded "not standard" by the C-99 rules...

What compiler are you using?

The compiler is Tiny C Compiler. Also, the ungetch() that I'm using is completely defined in the example, it's not a library function. The author explains his code as:

When an extra char is read, it is put in the buffer. When the next char is read, if there is anything in the buffer, it is pulled first.

Just using those two facts, and forgetting about compilers, etc... I don't see how it's possible to get more than one char in the buffer, since the process that adds another (reading) will always empty out the one that's there first.

Actually Windows prebuffers up to 128 characters from the keyboard and C may double buffer, providing even more....

The limitation --no matter how poorly documented in Tiny C-- is that ungetch() only back pushes one character.

As Tabstop points out the standard function ungetc() will pushback more than one character depending on the state of the input buffer. If the buffer has room for 10 characters, ok... if it only has room for 2... only two will be pushed back before an error is reported.

Originally Posted by CommonTater

Actually Windows prebuffers up to 128 characters from the keyboard and C may double buffer, providing even more....

The limitation --no matter how poorly documented in Tiny C-- is that ungetch() only back pushes one character.

As Tabstop points out the standard function ungetc() will pushback more than one character depending on the state of the input buffer. If the buffer has room for 10 characters, ok... if it only has room for 2... only two will be pushed back before an error is reported.

You know, I stared at the original code some more and now I think my confusion is not with getch() or ungetch(). It is with getop(). Since getop() always calls getch() before calling ungetch(), it is impossible to get more than one char into the buffer by using getop(). I guess in other usage though it would be possible to call ungetch() repeatedly which could fill its buffer up. I had thought the author created ungetch() solely for the getop() example, but I guess it is supposed to have a wider usage, which is why it has the error reporting capacity?

Originally Posted by CommonTater

Nope... it's an example in a book, designed to teach certain concepts and should not be seen as anything bigger or different than that. It's only provided to help you understand C programming... Real world programming is quite something else altogether.

Ok then, back to my original logic treating it only as an example in a book... in the context of that example, where getop() is the only function that calls ungetch(), is it possible to trigger the ungetch error message "too many characters"? I don't think it is possible... but at first I thought that I must be wrong, since why would the author include an error message that cannot be produced in the context of his example? That's what led me to ask the Q here.

But somebody else said that ungetch() is used more throughout the rest of the book, so that is probably why he included the error message, I'm guessing now.

Originally Posted by The111

I don't think it is possible... but at first I thought that I must be wrong, since why would the author include an error message that cannot be produced in the context of his example? That's what led me to ask the Q here.

The best error messages are the ones you never see... Programmers often include such code as a precaution because they know there are conditions (even if very rare) where a data loss might occur or because they know the function has certain limitations that might be problematic if someone modifies the code.

But somebody else said that ungetch() is used more throughout the rest of the book, so that is probably why he included the error message, I'm guessing now.

Frankly, I'd be prone to write that down to "a healthy dose of caution."... Something every programmer should posess so long as they don't jump over into paranoia about it.