php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #28273 feof() doesn't return TRUE when invalid file handle is passed to it
Submitted: 2004-05-04 15:58 UTC Modified: 2004-05-07 17:50 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: mikeboulet at newfangled dot com Assigned:
Status: Not a bug Package: Filesystem function related
PHP Version: 4.3.6 OS: Redhat 7.2 or Redhat AS 2.1
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mikeboulet at newfangled dot com
New email:
PHP Version: OS:

 

 [2004-05-04 15:58 UTC] mikeboulet at newfangled dot com
Description:
------------
When a fopen() is done on a file that has permissions that are set to not allow the current process user to read it or the file doesn't exist it returns false. This is expected. The problem is when feof() is fed the invalid handle it doesn't return TRUE() thus creating an infinite loop in the following code example. 


Reproduce code:
---------------
<?php
$fp = fopen( 't.txt', 'r' );

while( !feof( $fp ) )
{
    print fgets( $fp );
}

fclose( $fp );
?>

Expected result:
----------------
feof() would return TRUE to cancel the loop and the script would end. There would of course be warnings because of the invalid file handle, but that is expected.

There should be better error handling on the developers part and catch the invalid file handle, but I would expect the file functions to handle this situation accordingly.

Actual result:
--------------
Inifinite loop

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-05-04 16:46 UTC] abies@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

feof() does exactly what it\'s supposed to. 
 [2004-05-04 17:26 UTC] mikeboulet at newfangled dot com
I argue that it is a bug and that it was already addressed in a similar problem 

see http://bugs.php.net/bug.php?id=25939.

Basically while in the while( feof() ) loop the socket goes away due to network failure and the stream is no longer there. This causes an infinite loop in 4.3.4 because feof() would not return TRUE. In 4.3.5 they changed this behavior to return TRUE on socket failure. This would be similar to saying the file handle is not valid and there is nothing there feof() thus we are at the end of nothing. I guess you could say we are at begining of nothing.

I understand this is more of a symantics issue than a bug. If you google 'feof infinite php' you will see that there are a lot of people that get stung by this issue. Maybe it should be changed to get around a common problem.

What do you think?
 [2004-05-05 22:38 UTC] sniper@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.


 [2004-05-06 15:04 UTC] mikeboulet at newfangled dot com
Problem still persists in 4.3.6.
 [2004-05-07 17:50 UTC] iliaa@php.net
Works fine with latest CVS: 
<?php 
$fp = @fopen('/etc/passwd-', 'r' ); 
var_dump($fp, feof( $fp )); 
?> 
 
prints bool(false) twice as it should. 
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 28 23:01:32 2024 UTC