# new bug in 5.1.0b3 with length param in fread() with local files - Thread: https://externals.io/message/17371 - Original archive: https://news-web.php.net/php.internals/17371 - Started by Greg Beaver on 2005-07-22T04:08:02+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #17371 — Greg Beaver — 2005-07-22T04:08:02+00:00 URL: https://externals.io/message/17371#17371 Hi, I have noticed that `fread()`'s behavior has changed between PHP 5.0.4 and PHP 5.1.0b3. Basically, http://pear.chiaraquartet.net/go-pear.phar works in PHP 5.0.4 and fails in 5.1.0b3 because of this change. The line in question of the .phar from PHP_Archive is: fread($this->_file, $this->internalFileLength + $this->footerLength); Basically, a .phar is a .tar. For files inside the .phar larger than 16000 bytes, the fread above fails with the incorrect error message: PHP Warning: `fread()`: Length parameter must be greater than 0 in c:\php5\pear\PHP\Archive.php on line 193 Note that the failure is OS-independent. However, the actual length parameter is 21,155, which is not less than zero, unless you consider it to be a negative number in binary. After the fread in PHP 5.0.4, `ftell()` reveals that the pointer has advanced to 22016, whereas in 5.1.0b3, it has only advanced to 16384. According to the notes in http://bugs.php.net/bug.php?id=30936 this should work with a local file, so should I re-open 30936, or is this a new bug? Greg --- ## #17379 — Wez Furlong — 2005-07-22T12:36:28+00:00 URL: https://externals.io/message/17371#17379 · In reply to: #17371 If you've spotted a behaviour change, open a new bug with a short self-contained reproducing script. I suspect some kind of engine bug here, because what you've described doesn't make sense :) That warning about the length comes from this code in the fread function: len = Z_LVAL_PP(arg2); if (len <= 0) { php_error_docref(NULL TSRMLS_CC, E_WARNING, "Length parameter must be greater than 0"); RETURN_FALSE; } So either you are passing in something that evaluates as 0 (or less), or something is corrupting memory and breaking the length value by the time it reaches `fread()`. I'd recommend running your script under valgrind (--disable-memory-manager when you configure PHP) and see if it reports anything bad. --Wez. > Hi, > > I have noticed that `fread()`'s behavior has changed between PHP 5.0.4 and > PHP 5.1.0b3. Basically, http://pear.chiaraquartet.net/go-pear.phar > works in PHP 5.0.4 and fails in 5.1.0b3 because of this change. The > line in question of the .phar from PHP_Archive is: > > fread($this->_file, $this->internalFileLength + > $this->footerLength); > > Basically, a .phar is a .tar. For files inside the .phar larger than > 16000 bytes, the fread above fails with the incorrect error message: > > PHP Warning: `fread()`: Length parameter must be greater than 0 in > c:\php5\pear\PHP\Archive.php on line 193 > > Note that the failure is OS-independent. > > However, the actual length parameter is 21,155, which is not less than > zero, unless you consider it to be a negative number in binary. After > the fread in PHP 5.0.4, `ftell()` reveals that the pointer has advanced to > 22016, whereas in 5.1.0b3, it has only advanced to 16384. > > According to the notes in http://bugs.php.net/bug.php?id=30936 this > should work with a local file, so should I re-open 30936, or is this a > new bug? > > Greg --- ## #17385 — Greg Beaver — 2005-07-22T15:57:37+00:00 URL: https://externals.io/message/17371#17385 · In reply to: #17379 Wez Furlong wrote: > If you've spotted a behaviour change, open a new bug with a short > self-contained reproducing script. I suspect some kind of engine bug > here, because what you've described doesn't make sense :) > > That warning about the length comes from this code in the fread function: > > len = Z_LVAL_PP(arg2); > if (len <= 0) { > php_error_docref(NULL TSRMLS_CC, E_WARNING, "Length parameter > must be greater than 0"); > RETURN_FALSE; > } > > So either you are passing in something that evaluates as 0 (or less), > or something is corrupting memory and breaking the length value by the > time it reaches `fread()`. In the attempt to find a short reproducing test script, I determined that the warning was caused by an earlier iteration through the method that uses fread. So, the warning was valid (0 was being passed in). What this means, however, is that the script is in fact simply failing to read in the requested amount with no warning at all. I'll have a test script shortly for the bug report. Greg --- ## #17394 — Andi Gutmans — 2005-07-25T20:40:26+00:00 URL: https://externals.io/message/17371#17394 · In reply to: #17371 Has anyone had a chance to look at this problem? At 10:08 PM 7/21/2005 -0600, Greg Beaver wrote: >Hi, > >I have noticed that `fread()`'s behavior has changed between PHP 5.0.4 and >PHP 5.1.0b3. Basically, http://pear.chiaraquartet.net/go-pear.phar works >in PHP 5.0.4 and fails in 5.1.0b3 because of this change. The line in >question of the .phar from PHP_Archive is: > > fread($this->_file, $this->internalFileLength + $this->footerLength); > >Basically, a .phar is a .tar. For files inside the .phar larger than >16000 bytes, the fread above fails with the incorrect error message: > >PHP Warning: `fread()`: Length parameter must be greater than 0 in >c:\php5\pear\PHP\Archive.php on line 193 > >Note that the failure is OS-independent. > >However, the actual length parameter is 21,155, which is not less than >zero, unless you consider it to be a negative number in binary. After the >fread in PHP 5.0.4, `ftell()` reveals that the pointer has advanced to >22016, whereas in 5.1.0b3, it has only advanced to 16384. > >According to the notes in http://bugs.php.net/bug.php?id=30936 this should >work with a local file, so should I re-open 30936, or is this a new bug? > >Greg --- ## #17415 — Wez Furlong — 2005-07-26T19:45:28+00:00 URL: https://externals.io/message/17371#17415 · In reply to: #17394 From the description, it doesn't sound like a bug. Awaiting more details. --Wez. > Has anyone had a chance to look at this problem? > > At 10:08 PM 7/21/2005 -0600, Greg Beaver wrote: > > […]