Bug #80339 [Com]: fatal error on calling strrpos

From: Date: Tue, 12 Apr 2022 15:44:44 +0000
Subject: Bug #80339 [Com]: fatal error on calling strrpos
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-240905@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=80339&edit=1 ID: 80339 Comment by: seb dot gibbs at ymail dot com Reported by: info at backups dot nl Summary: fatal error on calling strrpos Status: Duplicate Type: Bug Package: *General Issues Operating System: ubuntu server PHP Version: 8.0.0RC3 Block user comment: N Private report: N New Comment: strrpos - appears to return the character after the found position (about 10% of the time in my example code: $find = 'Baden-Württemberg,"Karlsruhe'; $filename = 'data/sources/db-ip.com/dbip-city-lite.csv'; $f = fopen($filename,'r'); //stream_set_read_buffer($f,$b); $t1 = hrtime(true); do { $line = ffindline($f,$find); if ($line == false) break; echo '<br>'.$line; } while (true); $t2 = hrtime(true); $t = ($t2-$t1)/1000000; echo '<br> '.(number_format($t,10).'ms '); fclose($f); function ffindline($f,$find,$linefeed="\n") { $p = ftell($f); $b = 20000; //- block size, also must be bigger than largest line size do $data = stream_get_line($f,$b,$find); while (ftell($f)===($p+=$b)); if (feof($f)) return false; $p = strrpos($data,$linefeed); echo ' [found:'.urlencode(substr($data,$p,strlen($find))) .'] '; if ($p===false) echo 'ERROR'; fseek($f,$p-strlen($find)-strlen($data)-strlen($linefeed),SEEK_CUR); stream_get_line($f,$b,$linefeed); $data = stream_get_line($f,$b,$linefeed); return $data; } Previous Comments: ------------------------------------------------------------------------ [2020-11-09 07:24:08] requinix@php.net @info: Harald is not a PHP representative. He is a troll. We're sorry you had to deal with his abuse but please ignore him. ------------------------------------------------------------------------ [2020-11-09 07:18:29] info at backups dot nl @nikic@php.net Thanks for the reply. Just so you know what is happening in your backend. I got this email from one of you called harry@rhsoft.net with this text. Where the words starting with F and I where written out completely. "can you f..... i.... stop opening a new vugreport for the same issue every 5 minutes? fix your code mess - nobody right in his mind is calling functions when a simple empty() check which is a language construct can avoid the *slow and expensive* function call" The reason i by accident posted multiple messages is that when entering my second message and submitting it i got several times a error about the patch that was needed. I was in the assumption that the message therefor did not submit. So i tried again, and again. I apologize for that. BUT THAT does not mean that Reindl Harald of you can send me such a private email ! Is this how The PHP.NET handles stuff? ------------------------------------------------------------------------ [2020-11-08 19:40:50] nikic@php.net Don't think there's much point in taking this to the mailing list, I doubt the resolution is going to change. Out of bounds indexes have always been considered an error condition for strpos-style functions (see for example https://3v4l.org/30HoR). These error conditions have become exceptions in PHP 8 in line with general guidelines. strrpos() in particular did not throw a warning before due to an implementation oversight -- however, this has been fixed in PHP 8 as the treatment of strpos() and strrpos() must be the same for obvious consistency reasons. ------------------------------------------------------------------------ [2020-11-08 18:49:24] girgias@php.net Please discuss this on the internals mailing list instead of opening duplicate bug reports. ------------------------------------------------------------------------ [2020-11-08 18:48:03] info at backups dot nl Description: ------------ I get a fatal error on calling strrpos when the haystack is empty. I now have to check the haystack before calling strrpos, $haystack=''; $pos = strrpos($haystack, '.', -1); May other issue was brutally closed for replies. https://bugs.php.net/bug.php?id=80336 I don't understand why as the last answer given by you is incorrect. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=80339&edit=1

« previous php.bugs (#240905) next »