Nick Ing-Simmons <[EMAIL PROTECTED]> writes: >Craig A. Berry <[EMAIL PROTECTED]> writes: >> Displaying source in a caller of the current routine >> 51605: if (PerlSIO_ungetc(ch, s) != ch) >>DBG> show calls >> module name routine name line rel PC abs PC >> SHARE$DECC$SHR_CODE0 00000000000ABC50 FFFFFFFF80607C50 >>----- the above appears to be a null frame in the same scope as the frame below >>*PERLIO PerlIOStdio_unread >> 51605 0000000000005950 00000000004408E0 > >Looks like VMS's oddities has found a PerlIO oddity. >This call sequence looks very strange.
Okay - on further poking about I see that the unread() is "normal" for current :encoding code. :encoding is using PerlIO in a manner which should work - though is probably sub-optimal for what it is using it for - made a note to re-examine that later. So what VMS has discovered is that there is a class of valid stdio implementations (of which VMS is an example) where existing PerlIOStdio_unread() does not work - which is blindingly obvious _now_. As Nick C points out just because ungetc() succeeds does NOT mean char has gone into _the_ buffer we are snooping. In fact if we can do stdio buffer snooping then implementation is stupid, (we should put data in buffer ourselves), and if we can't then falling back to PerlIOBase_unread() (which pushed a temporary layer to hold the data) would be better. All in all not one of my better bits of code. Quick fix patch to follow, followed by a more optimal one. > >>*PERLIO Perl_PerlIO_unread >> 50367 0000000000002C78 000000000043DC08 >> 000000000003285C 000000000099A85C -- Nick Ing-Simmons http://www.ni-s.u-net.com/
