At 10:25 AM 5/22/2002 -0400, Green, Paul wrote: >Craig A. Berry [mailto:[EMAIL PROTECTED]] writes:
>> **PERLIO\PerlIOStdio_unread\s >> _cnt: 2789 >> _ptr: 8839168 >> _base: 8839168 >> _flag: 73 >_cnt is the number of valid bytes remaining in the input buffer. >_ptr is the address of the next valid byte. >_base is the address of the start of the buffer. >_file is the file descriptor of this io attachment. >_flag is where EOF, IOERR, etc. are kept. Thanks, Paul. So it looks like we are at the beginning of the buffer and trying to push back one byte. That makes sense because I think this is precisely the condition where the macro punts and calls the C library version, which is definitely what is happening. I guess that makes sense in that anything that could involve refilling or adjusting the size or location of the buffer would have to be handled internally. I forgot to mention before that the ungetc succeeds. However, the contents of the _iobuf structure are identical before and after the ungetc, which is not what I would have expected. >The comment in iperlsys.h that says "Unusual definition of ungetc() here to >accomodate fast_sv_gets()' >belief that it can mix getc/ungetc with reads from stdio buffer" is odd >because I don't see any language in the C standard that would prohibit such >a mixing. If you read from the buffer without updating the pointer and the counter in the _iobuf structure, then I could see how that would throw off ungetc. I assumed that's what the comment meant, but I don't know if fast_sv_gets() is really guilty of that. >My tentative suggestion is to nix the special definition of ungetc() for VMS >and see what happens if you use the standard logic. Been there, done that. As I recall miniperl couldn't even read in a script to parse.
