Nicholas Clark <[EMAIL PROTECTED]> writes: >> I am hoping that problem is that ungetc() is loosing an octet >> (why is that not noticed in other tests) or perhaps that multiple-ungetc >> re-orders the octets. > ^^^^^^^^^^^^^^^ > >Alarm bells ring in my head at this point. > >What do you mean multiple ungetc? >If that's going to stdio, ANSI only guarantee that the first ungetc will >succeed.
I know that. ANSI C does not allow you to snoop the buffer either but we do that as well. It is also not unreasonable if buffer is snoopable to expect that we can "unget" back to begining of the buffer. However, AFAIK all we _require_ is one pushback as Stdio_fill does just error checked version of ungetc(fgetc(f),f). Stdio_unread uses ungetc too - and believes the error return it gets and if it fails falls back to pushing a temporary :pending layer. So if ungetc lies about failure, or claims it succeeds but re-orders the data we could see something like we have on VMS - if we are doing _unread - which we should not be at this point? It is also possible that most stdio's ungetc do allow multiple pushback, and that bug is in the fallback code which noone else has tried. -- Nick Ing-Simmons http://www.ni-s.u-net.com/
