I/O status Re: SPUG: proper checking of file status after read?

[Ben Reser]

On Thu, Sep 18, 2003 at 08:12:48PM -0700, Fred Morris wrote:
> At 9:08 AM 9/18/03, Ben Reser wrote:
> >if (open(FH, $filename)) {
> >    # Here $! is meaningless.
> >    ...
> >} else {
> >    # ONLY here is $! meaningful.
> >    ...
> >    # Already here $! might be meaningless.
> >}
> ># Since here we might have either success or failure,
> ># here $! is meaningless.
> 
> In the real world, this has never been the case, but thanks for pointing it
> out. This sounds like bad documentation more than anything else: there are
> side effects which call system libraries which mere mortals are unaware or
> uninformed of. (Nobody's encountered crufty and perhaps slightly arrogant
> documentation before?) Or are we to believe that $! is used merely for
> scratch when the whim strikes?

What you seem to be missing is the key sentence in the following
paragraph:

> >A successful system or library call does not
> >set the variable to zero.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Which means, if errno got set for whatever reason previously it will
still be set even after a successful library call.  This is by *DESIGN*.
$! is not used to tell you that an error occured, the return value of
the operation tells you if it was successful or not.  It simply provides
you the error number of the *LAST* error.  

Theoretically you could work around this by setting $! to 0 prior to
starting your while loop.  But this is also possible to break.  Say perl
ends up calling some function to request some information be put in a
buffer and the buffer was too small so the call sets the errno.  Even if
perl handles this buffer issue for you, then the errno will be set.

At any rate I wouldn't consider the documentation wrong, crufty or
arrogant.

> Herein is the allusion to buffering gone bad... (do that, doesn't fail)
> 
> >@lines = <INFILE> or die "Error reading /path/spec: $!";
> 
> How is this different from a while loop on individual lines until
> (presumably) an undef occurs?

It's not different, except that it has error handling in a much simpler
way.  To try and detect and error while reading with while (<FH>) {...}
would be difficult.

> In the newer versions of Perl, (no I stand
> corrected, any version of Perl 5) this would fail if the file was empty.

I can't imagine why you wouldn't consider reading an empty
file an error condition...  If there's nothing to read it's not a
successful read.

> However, if there was no error, are you saying that $! is "meaningless"?
> This is the snag, you see.

If there is no error the die call never happens so $! is never used.

> And it's not just "any value", it's an ioctl.. every time.
> 
> As a matter of fact, I just tried your suggestion on an empty file with
> perl v5.8.0 i586-linux-thread-multi (plus SuSE patches) and by golly I got
> Inappropriate ioctl for device.
> 
> On 5.005_03 $! is .. well... false.
> 
> Anything else I missed here? Yes. The system with 5.5.3 is on an ext2 fs,
> and the system with 5.8.0 is reiserfs. FWIW.

reiserfs is considering the attempt to read an empty file an error and
setting errno.  ext2 apparently doesn't consider it as such.  Not all
filesystems are created equally.

However, perl does consider it an error because there is nothing to put
in the array i.e. the assignment failed.

> But again: I am sure that the file(s) in question in the real app are *not*
> empty. How does one check for a "no problem" condition when at end of
> file.. because we can ascertain, by both documentation and practice, that
> "end of file" is reached when the end of file is reached as well as when
> there is an I/O error.
> 
> Am I a flipper baby for wanting to be able to check for I/O read status?
> Does nobody do this? Wow.

This is generally not a concern when reading files in perl because perl
handles the I/O issues for you.  Sounds to me like you're trying to do
work that's already handled for you...

-- 
Ben Reser <ben at reser.org>
http://ben.reser.org

"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken