Hi all,
I'm not a PHP internals developer, but this might be a bug spread here and
there in the source. This coding pattern:
if(php_stream_read(..., n) != n){
php_error_docref(NULL TSRMLS_CC, E_SOMETHING, "Read error!");
seems wrong to me because there might be streams that returns less than
n bytes at once. When exactly n bytes are expected, not more not less,
a function similar to this one should be used instead:
int php_stream_read_fully(..., int n){
continue calling php_stream_read() until exactly n bytes are
collected, or a premature EOF, or I/O error
}
I ran into this issue passing a custom stream to getimagesize()
:
getimagesize("myprotocol://");
where myprotocol:// may, in some situations, return less bytes than
expected (see the http://php.net/manual/en/class.streamwrapper.php
wrapper class, stream_read() method). Looking at the implementation of
this function in ext/standard/image.c, I just found the pattern above.
If this is really a bug, many other functions might be affected.
Regards,
/|\ Umberto Salsi
/_/ www.icosaedro.it
Hi all,
I'm not a PHP internals developer, but this might be a bug spread here and
there in the source. This coding pattern:if(php_stream_read(..., n) != n){
php_error_docref(NULL TSRMLS_CC, E_SOMETHING, "Read error!");seems wrong to me because there might be streams that returns less than
n bytes at once. When exactly n bytes are expected, not more not less,
a function similar to this one should be used instead:int php_stream_read_fully(..., int n){
continue calling php_stream_read() until exactly n bytes are
collected, or a premature EOF, or I/O error
}I ran into this issue passing a custom stream to
getimagesize()
:getimagesize("myprotocol://");
where myprotocol:// may, in some situations, return less bytes than
expected (see the http://php.net/manual/en/class.streamwrapper.php
wrapper class, stream_read() method). Looking at the implementation of
this function in ext/standard/image.c, I just found the pattern above.
If this is really a bug, many other functions might be affected.
Why does your stream behave non-blocking by default? Unless explicitly
stated, those callees probably expect a blocking stream.
--
Regards,
Mike