Paul Green <[EMAIL PROTECTED]> writes:
>> >Break-points in PerlStdio_unread() would be informative - if
>> >we ever get there then VMS is going to exercise paths that
>> >other stdio's have not pipe-cleaned.
>>
>> Well, I'm in there now. I've been able to show that we only call
>> PerlSIO_ungetc once during the run of my reduced test program. The
>> character we are trying to unget is 0xF1 (0d241). Since I
>> end up in the middle of the C library when I step into
>> PerlSIO_ungetc, I think that tells us all the shenanigans the macro
>> goes through to avoid calling decc$ungetc are to no avail and it
>> does wind up calling it. I believe the reason is that
>> _ptr == _base and it will only do its pointer manipulations
>> when _ptr > _base. I don't know enough about what those things are
>> to know what that means, but here's what the _iobuf structure looks
>> like:
>>
>> **PERLIO\PerlIOStdio_unread\s
>> _cnt: 2789
>> _ptr: 8839168
>> _base: 8839168
>> _flag: 73
>> _padfile: 3
>> _pad1: 4
>> _pad2: 0
>> _file: 3
>
>_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.
>
>See stdio.h for the values of flag (_IOxxxx).
>
>It seems to me that it makes no sense to ungetc() before you have done a
>getc().
perlio isn't supposed to do that.
What it does is mimic what perl has done with stdio for years:
while (f->_cnt)
{
snoop f->_ptr
}
if (f->_cnt == 0) {
{
/* end of buffer get some more */
ungetc(fgetc(f),f);
resume snooping f->_ptr
}
It is expecting the fgetc to have advanced the f->_ptr and the ungetc()
to move it back to the begining of the buffer.
This is _supposed_ to be more portable than messing with ptr/cnt directly.
So calling ungetc() with ptr == buf "should never happen".
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
