Front page | perl.perl5.porters |
Postings from July 2001
On Fri, Jul 06, 2001 at 01:39:10PM +0100, Nick Ing-Simmons wrote:
> > pp_getc() calls is_eof() which does getc/ungetc
> > calls getc()
> >
> > [BTW, I see no logic in this sequence of events.]
>
> It is legacy scheme - for systems where we cannot snoop the buffer
> we ask (e.g.) stdio to get a char, if it succeeds we are not at EOF.
> But then we need to put char back.
We *can* snoop the buffer with PerlIO (and without it too in my setup).
> > if (ch == '\n')
> > {
> > if (b->ptr - 2 >= b->buf)
> > {
> >
> >Tracing through perlio.c shows how much EVIL it is. All 80K of it.
>
> If the handle is in text mode then '\n' should have come from a CRLF pair,
> so there should be room for it.
Absolutely not. It can com from CRLF or from a lone LF.
> All the handles should be binary() at the OS level.
This is unacceptable if the CRTL level CRLF handling is 10x as
efficient as PerlIO's (which I expect holds for EMX - and any other
sanely coded handler).
> If OS2's CRLF logic is solid an efficent then it may make sense to
> NOT use crlf layer but just use OS2's read/write directly.
Agreed...
> >In the example of Term::ReadKey, CRTL *knows* that TTYs should be opened
> >in the binary mode. PerlIO does not.
> >There are miriads of such special
> >cases.
>
> So get Term::ReadKey to tell PerlIO it should be binary.
You propose to duplicate the CRTL's knowledge of the system's
specifics in all the modules?
> >The task of CRNL translation is very quick and easy - with a proper
> >implementation.
>
> The main pain is getting tell() and seek() to work right.
This is just plain impossible without an enormous overhead of marking
each \n with whether it came from \n or \r\n.
A reasonable target is to make tell() work on the results of seek().
This is what EMX does, and what causes very few well-localized
complaints.
Ilya
Thread Previous
|
Thread Next