Craig A. Berry <[EMAIL PROTECTED]> writes: >At 05:04 PM 5/21/2002 +0100, Nick Ing-Simmons wrote: > >>We also have a quick-fix for 5.8 if you agree to it - lie about stdio's >>buffer snooping ability in "configure" so that perlio.c will choose >>:perlio as the default layer for implementation. > >I'm open to it and we might not even be lying.
Okay - can you do the PERLIO=perlio thing and run the whole test suite? If that looks "good" the above may suffice for 5.8 >It appears that ungetc's >pushback buffer is a separate and separately maintained thing from the >underlying stdio buffer, and knowledge of how the former gets updated from >the latter is not necessarily available outside the guts of the C RTL. The >docs to setvbuf() say that the stdio buffer size can range from 8192 to >32767, so the fact that we see problems at or near 16384 bytes into the file >is awfully suspicious; that's probably the default buffer size for a stream >file. > >>The finger now points at VMS specific "stdio" hackery which the :stdio >>layer is using. As that has probably been merged by several people - >>me who did not understand VMS C library and some VMS folk who did >>not understand perlio.c - and as the whole thing is wrapped in a horrible >>include file and #define forest a bug in there is quite likely. > >Indeed. The ungetc macro was already in perlsdio.h; I think it must have >originally been Charles Bailey's handiwork, which means the pointer >arithmetic and such are almost certainly correct but it wasn't necessarily >designed to work in the context of perlio layers. That should not matter - assuming it got copied over correctly from where-ever I found it it was working when perl was using FILE * and it is still manipulating a FILE * >To get -Duseperlio >working (about a year ago now), I copied it into iperlsys.h because without >it miniperl couldn't do the simplest things. All of which is to say I >didn't (and still don't) understand why it's necessary or what assumptions >it might be making that we are now violating. Neither do I :-( > >>I would be tempted to make a vms_ungetc() _function_ which incorporated >>the current macro, point iperlsys.h at that rather than the macro >>and add some debug to prove it was getting called >>and to log what the vms_problem.t 'ungets' and what state the ptr etc. >>are in when it does it. > >Something like that should be doable. It might also be possible to set >watchpoints on the pieces of the FILE structure. > >In all of the above I feel that I'm speaking a language I don't quite >understand. Is there a good beginner's guide to struct _iobuf and friends? Not really - their weirdness and inconsistency was one reason we embarked on PerlIO in the first place. -- Nick Ing-Simmons http://www.ni-s.u-net.com/
