Front page | perl.perl5.porters |
Postings from June 2009
On Sat, Jun 20, 2009 at 2:30 PM, Michael G Schwern<schwern@pobox.com> wrote: > Stepan Kasal wrote: >> Perhaps the perl interpreter should make sure that eof is unset if an >> error appears, so that we can look at it. If you already know that you've hit end-of-file, why does it matter that subsequent attempts to perform I/O on that stream generate errors? Likely I'm misunderstanding -- I just don't know how. >> Or should we rather introduce ferror to perl? > > It might be nice to have errors attached to filehandles. That pushes use more > towards making real IO objects. You mean like: =item B<PerlIO_error(f)> This corresponds to ferror(). Returns a true/false indication of whether there has been an IO error on the handle. from perlapio.pod? > But it only helps when there's a filehandle. unlink(), chdir(), mkdir(), > etc... don't have a filehandle. But these are pretty atomic and don't involve PerlIO as far as I know. Handling errors from these is really a different type of problem from handling errors while reading from or writing to a stream. >> Better yet, wouldn't it be possible to make sure that $! is not set >> by a successful io operation? >> Either It could be cleared after every successful io operation. >> (Or the value could be saved before the io call and then restored if >> the io was successful, so that backward compatibility with broken >> perl code is maintained.) I think the difficulty here is defining what is or is not an "io operation." Percolating data through the PerlIO layers may or may not trigger various system calls that may or may not set errno. Scaling back the number of cases where PerlIO sets errno is a start, and we've done that. Blindly clearing errors seems a little dangerous to me. I'm sure there's more work to be done here. It's not my particular itch to scratch.Thread Previous | Thread Next