Req #61255 [Opn->Wfx]: Unserialize should handle incorrect or missing string-length
Edit report at https://bugs.php.net/bug.php?id=61255&edit=1
ID: 61255
Updated by: cataphr...@php.net
Reported by:mi+php at aldan dot algebra dot com
Summary:Unserialize should handle incorrect or missing
string-length
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:*Data Exchange functions
Operating System: All
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
As mentioned, " is not escaped, making the length required. This is not even
considering whether it would be a good idea to otherwise make unserialize lax.
You are of course free to write your own serialization/unserialization library,
like igbinary.
Previous Comments:
[2012-03-03 04:18:37] mi+php at aldan dot algebra dot com
If the length is what's driving the parsing, then why are the strings S2 and S3
empty in my test? Shouldn't S2 be '123456' and S3 be '1234567"'?
[2012-03-03 00:45:48] anon at anon dot anon
It depends on the lengths because the strings aren't escaped. serialize('"') =
s:1:""";
[2012-03-02 22:26:46] mi+php at aldan dot algebra dot com
Description:
A serializing string "foo" produces an intuitive result 's:3:"foo"' and
unserialize() properly decodes that back.
It would be useful, however, if the unserialize function could handle (even if
less efficiently) cases, where the string-length is missing or even specified
incorrectly. Currently any such mismatches result in empty output from the
function, even though `s:"foo"' or `s::"foo"' or even `s:4:"foo"' is no harder
to understand.
The feature would be of help to those of us, who need to a massive
search/replace in the dump of serialized objects.
Test script:
---
" . unserialize($s1) . "<\n";
print "S2: >" . unserialize($s2) . "<\n";
print "S3: >" . unserialize($s3) . "<\n";
print "S4: >" . unserialize($s4) . "<\n";
?>
Expected result:
S1: >1234567<
S2: >1234567<
S3: >1234567<
S4: >1234567<
Actual result:
--
S1: >1234567<
S2: ><
S3: ><
S4: ><
--
Edit this bug report at https://bugs.php.net/bug.php?id=61255&edit=1
[PHP-BUG] Bug #61264 [NEW]: xmlrpc_parse_method_descriptions leaks temporary variable
From: nikic Operating system: PHP version: Irrelevant Package: XMLRPC-EPI related Bug Type: Bug Bug description:xmlrpc_parse_method_descriptions leaks temporary variable Description: foo XML; var_dump(xmlrpc_parse_method_descriptions($xml)); Leaks, because the retval (http://lxr.php.net/xref/PHP_TRUNK/ext/xmlrpc/xmlrpc-epi-php.c#1240) is not dtor'd. -- Edit bug report at https://bugs.php.net/bug.php?id=61264&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61264&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61264&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61264&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61264&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61264&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61264&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61264&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61264&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61264&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61264&r=support Expected behavior: https://bugs.php.net/fix.php?id=61264&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61264&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61264&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61264&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61264&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61264&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61264&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61264&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61264&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61264&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61264&r=mysqlcfg
Bug #61264 [Opn->Csd]: xmlrpc_parse_method_descriptions leaks temporary variable
Edit report at https://bugs.php.net/bug.php?id=61264&edit=1 ID: 61264 Updated by: ni...@php.net Reported by:ni...@php.net Summary:xmlrpc_parse_method_descriptions leaks temporary variable -Status: Open +Status: Closed Type: Bug Package:XMLRPC-EPI related PHP Version:Irrelevant -Assigned To: +Assigned To:nikic Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-03-03 12:46:10] ni...@php.net Automatic comment from SVN on behalf of nikic Revision: http://svn.php.net/viewvc/?view=revision&revision=323850 Log: Fix bug #61264: xmlrpc_parse_method_descriptions leaks temporary variable [2012-03-03 12:37:50] ni...@php.net Description: foo XML; var_dump(xmlrpc_parse_method_descriptions($xml)); Leaks, because the retval (http://lxr.php.net/xref/PHP_TRUNK/ext/xmlrpc/xmlrpc-epi-php.c#1240) is not dtor'd. -- Edit this bug report at https://bugs.php.net/bug.php?id=61264&edit=1
[PHP-BUG] Req #61265 [NEW]: __autoload should know about traits
From: Operating system: PHP version: 5.4.0 Package: Class/Object related Bug Type: Feature/Change Request Bug description:__autoload should know about traits Description: Currently, __autoload is automatically called when a class is not found. As of 5.4.0, it is also called when a trait is not found. It is also called when an interface is not found. Unfortunately, there is no way to understand what type of resource is being autoloaded. So I suggest that a second optional argument is added to __autoload. It can receive three possible values from the PHP engine - for example: AUTOLOAD_CLASS, AUTOLOAD_TRAIT and AUTOLOAD_INSTANCE. This way, a better autoload handling can be achieved. -- Edit bug report at https://bugs.php.net/bug.php?id=61265&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61265&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61265&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61265&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61265&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61265&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61265&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61265&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61265&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61265&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61265&r=support Expected behavior: https://bugs.php.net/fix.php?id=61265&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61265&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61265&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61265&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61265&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61265&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61265&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61265&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61265&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61265&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61265&r=mysqlcfg
[PHP-BUG] Bug #61266 [NEW]: pg_affected_rows inconsistent behavior (depends on PostgreSQL server version)
From:
Operating system: all
PHP version: Irrelevant
Package: PostgreSQL related
Bug Type: Bug
Bug description:pg_affected_rows inconsistent behavior (depends on PostgreSQL
server version)
Description:
According to the manual, pg_affected_rows should returns "the number of
tuples
(instances/records/rows) affected by INSERT, UPDATE, and DELETE queries.".
The
manual details : "The number of rows affected by the query. If no tuple is
affected, it will return 0.".
PHP pg_affected_rows uses libpq's PQcmdTuples() to implement this:
PHP_FUNCTION(pg_affected_rows)
{
php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAM_PASSTHRU,PHP_PG_CMD_TUPLES);
}
static void php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAMETERS, int
entry_type)
{
[...]
case PHP_PG_CMD_TUPLES:
Z_LVAL_P(return_value) = atoi(PQcmdTuples(pgsql_result));
But server's answers to PQcmdTuples() commands changed since PostgreSQL
9.0.
When executed after a SELECT, PostgreSQL < 9.0 returned 0 (as in "0 rows
were
affected"); starting with PostgreSQL 9.0, the server returns the number of
SELECTed rows.
See how the PQcmdTuples documentation was updated after pg 9:
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
PostgreSQL C API doesn't actually offers a "tell me how many rows were
written/modified" function. But we can restore the previous
pg_affected_rows
behavior, and enjoy consistent results no matter which server version we
run
against, by unconditionally returning 0 after a SELECT.
This is what the attached patch does, identifying the SELECT with
PQresultStatus() value (which returns PGRES_COMMAND_OK after a successful
DML,
as opposed to PGRES_TUPLES_OK after a SELECT, etc).
If you ask so, I can also provide an alternative patch (which tests the
string
returned by PQcmdStatus(), a bit ugly imo) and/or an unit test script for
PHP's
test framework.
Test script:
---
// Bug on a PostgreSQL >= 9.0 server, ok on older versions.
$dbh = pg_pconnect("dbname=postgres host=localhost user=postgres
port=5432");
$q = pg_query($dbh, "SELECT * from generate_series(1, 42);");
var_dump(pg_affected_rows($q));
Expected result:
int(0)
Actual result:
--
int(42)
--
Edit bug report at https://bugs.php.net/bug.php?id=61266&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61266&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61266&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61266&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61266&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61266&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61266&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61266&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61266&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61266&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61266&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61266&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61266&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61266&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61266&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61266&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61266&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61266&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61266&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61266&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61266&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61266&r=mysqlcfg
[PHP-BUG] Bug #61267 [NEW]: pdo_pgsql's PDO::exec() returns the number of SELECTed rows on postgresql >= 9.
From:
Operating system: all
PHP version: Irrelevant
Package: PDO related
Bug Type: Bug
Bug description:pdo_pgsql's PDO::exec() returns the number of SELECTed rows on
postgresql >= 9.
Description:
After executing a SELECT statement, PDO::exec() -using the pdo_pgsql driver
and
running against a PostgreSQL server older than 9.0- will always returns 0,
as
does the pdo_mysql and pdo_sqlite drivers. ie. this is the exepected
behaviour
(though to be precise, the PDO::exec() documentation stipulate :
"PDO::exec()
does not return results from a SELECT statement.").
But when executed against a PostgreSQL >= 9.0 server, this very same php
client
and select statement will return the number of selected rows. This is due
to a
server side change in how PostgreSQL servers answers to libpqs's
PQcmdTuples()
commands (PQcmdTuples() being used as the PDO::exec() return value, via
pdo_pgsql pgsql_handle_doer() function).
This server-side change is visible by comparing this command's
documentation for
different PostgreSQL versions :
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
See also the bug in pg_affected_rows https://bugs.php.net/bug.php?id=61266
I
just reported.
The attached patch does check whether the PDO::exec() param was a
(successful)
DML statement before using PQcmdTuples() to return the number of affected
rows.
Also attached, a test script for PHP's unit test infrastructure.
Test script:
---
// Bugs on PostgreSQL >= 9.0 server (but ok on previous versions)
$dbh = new PDO("pgsql:dbname=postgres ;host=localhost", 'postgres');
var_dump($dbh->exec("SELECT * from generate_series(1, 42);"));
Expected result:
int(0)
Actual result:
--
int(42)
--
Edit bug report at https://bugs.php.net/bug.php?id=61267&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61267&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61267&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61267&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61267&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61267&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61267&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61267&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61267&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61267&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61267&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61267&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61267&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61267&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61267&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61267&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61267&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61267&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61267&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61267&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61267&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61267&r=mysqlcfg
Bug #61256 [Opn->Nab]: Hex numbers parsing error
Edit report at https://bugs.php.net/bug.php?id=61256&edit=1 ID: 61256 Updated by: pierr...@php.net Reported by:balancer at balancer dot ru Summary:Hex numbers parsing error -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Gentoo Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. This bug is the same as #61095 which was fixed. Previous Comments: [2012-03-02 23:15:08] balancer at balancer dot ru Description: Incorrect parsing 0xNN numbers with operators Test script: --- $ php -r 'var_dump(0x0+1);' int(2) $ php -r 'var_dump(0x0 + 1);' int(1) $ php -r 'var_dump(0x0+10);' int(26) $ php -r 'var_dump(0x0 + 10);' int(10) $ php -r 'var_dump(0x0-10);' int(-26) $ php -r 'var_dump(0x0 - 10);' int(-10) -- Edit this bug report at https://bugs.php.net/bug.php?id=61256&edit=1
Req #55166 [Com]: Implement a global limit to the overall number of php processes
Edit report at https://bugs.php.net/bug.php?id=55166&edit=1 ID: 55166 Comment by: trollofdarkness at gmail dot com Reported by:trollofdarkness at gmail dot com Summary:Implement a global limit to the overall number of php processes Status: Closed Type: Feature/Change Request Package:FPM related PHP Version:5.3SVN-2011-07-09 (SVN) Assigned To:fat Block user comment: N Private report: N New Comment: A small note to those ones who will read this entry : When committed into 5.3.4, the directive has been renamed from "max_total_process" to "process.max". I don't know whether it has been added in the documentation yet, I found by digging into the code. Previous Comments: [2011-10-08 19:53:03] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-10-08 13:47:29] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=317896 Log: - Backported FR #55166 from 5.4 branch (Added process.max to control the number of process FPM can fork) [2011-09-27 10:46:22] albertcasademont at gmail dot com This is an amazing feature guys, thank you very much! Any news on backporting the patch to 5.3? Thanks! [2011-07-17 17:22:33] trollofdarkness at gmail dot com Ok :) Thank you for your reactivity ;) [2011-07-17 07:43:22] f...@php.net Commited into 5.4. Thx you very much for your help. I'll wait 5.3.7 is out before backporting this to 5.3 branch. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55166 -- Edit this bug report at https://bugs.php.net/bug.php?id=55166&edit=1
Bug #61245 [Opn]: ResourceBundle can't load .dat resources
Edit report at https://bugs.php.net/bug.php?id=61245&edit=1
ID: 61245
Updated by: cataphr...@php.net
Reported by:jinmoku at hotmail dot com
Summary:ResourceBundle can't load .dat resources
Status: Open
Type: Bug
Package:I18N and L10N related
Operating System: Windows 7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
This is likely due to an old version of ICU being shipped with PHP 5.4.0
binaries. Pierre tells me these will be updated with PHP 5.4.1.
Previous Comments:
[2012-03-02 14:09:48] jinmoku at hotmail dot com
Description:
ResourceBundle can't load .dat resource (work with 5.3)
Test script:
---
$bundle = new \ResourceBundle('fr', __DIR__.'/icudt48l');
var_dump(intl_get_error_message());
Expected result:
U_ZERO_ERROR
Actual result:
--
resourcebundle_ctor: Cannot load libICU resource bundle:
U_MISSING_RESOURCE_ERROR
--
Edit this bug report at https://bugs.php.net/bug.php?id=61245&edit=1
Bug #61250 [Csd->Nab]: php_mysqlnd_config.h not found
Edit report at https://bugs.php.net/bug.php?id=61250&edit=1 ID: 61250 Updated by: cataphr...@php.net Reported by:iamhiddensomewhere at gmail dot com Summary:php_mysqlnd_config.h not found -Status: Closed +Status: Not a bug Type: Bug Package:MySQL related Operating System: Linux 2.6.32-5-amd64 PHP Version:5.4.0 Block user comment: N Private report: N Previous Comments: [2012-03-02 20:38:51] iamhiddensomewhere at gmail dot com mysqlnd wasn't enabled via --enable-mysqlnd, this bug is now invalid. [2012-03-02 19:25:15] iamhiddensomewhere at gmail dot com Description: Trying to build ext/pdo_mysql or ext/mysqli (phpize && ./configure && make && make install) doesn't work (there are various references to ext/mysqlnd which should be ../mysqlnd) but after fixing those broken references there's a file missing which is called from an include statement. At ext/mysqlnd/mysqlnd_portability.h:40 the file 'php_mysqlnd_config.h' is referenced but nowhere to be found. This prevents ext/pdo_mysql or ext/mysqli from being built. Expected result: Compiling ext/pdo_mysql or ext/mysqli successfully. Actual result: -- make fails with (for example) In file included from /opt/phpfarm/src/php- 5.4.0/ext/mysqli/../mysqlnd/mysqlnd.h:60, from /opt/phpfarm/src/php- 5.4.0/ext/mysqli/php_mysqli_structs.h:42, from /opt/phpfarm/src/php-5.4.0/ext/mysqli/mysqli.c:34: /opt/phpfarm/src/php-5.4.0/ext/mysqli/../mysqlnd/mysqlnd_portability.h:40:36: error: ./php_mysqlnd_config.h: No such file or directory make: *** [mysqli.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=61250&edit=1
Bug #60940 [Opn->Csd]: SplFileInfo::getLinkTarget fails
Edit report at https://bugs.php.net/bug.php?id=60940&edit=1
ID: 60940
Updated by: il...@php.net
Reported by:aheadley at nexcess dot net
Summary:SplFileInfo::getLinkTarget fails
-Status: Open
+Status: Closed
Type: Bug
Package:SPL related
Operating System: Fedora 16
PHP Version:5.3SVN-2012-01-31 (snap)
-Assigned To:
+Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
Previous Comments:
[2012-02-04 17:58:47] php-dev at zerocue dot com
Confirmed works in 5.4RC7 and trunk as well.
[2012-01-31 21:57:58] aheadley at nexcess dot net
It also appears to be working in 5.4.0RC6.
[2012-01-31 21:38:42] aheadley at nexcess dot net
Description:
SplFileInfo::getLinkTarget
(http://www.php.net/manual/en/splfileinfo.getlinktarget.php) does not seem to
work at all. It fails with a "Unable to read link , error:
Invalid argument" message. Reproduced on 5.3.8 and 5.3.10-dev snapshot
(201201312030) but works on 5.2.17.
This similar but not quite the same as #51804
(https://bugs.php.net/bug.php?id=51804)
Test script:
---
touch('testfile');
symlink('testfile', 'testlink');
$f = new SplFileInfo( 'testlink' );
printf( 'readlink: %s'.PHP_EOL, readlink( $f->getPathname() ) );
printf( 'SplFileInfo::getLinkTarget: %s'.PHP_EOL, $f->getLinkTarget() );
Expected result:
readlink: testfile
SplFileInfo::getLinkTarget: testfile
Actual result:
--
readlink: testfile
Fatal error: Uncaught exception 'RuntimeException' with message 'Unable to read
link testlink, error: Invalid argument' in
/home/aheadley/Desktop/testing/test.php:6
Stack trace:
#0 /home/aheadley/Desktop/testing/test.php(6): SplFileInfo->getLinkTarget()
#1 {main}
thrown in /home/aheadley/Desktop/testing/test.php on line 6
--
Edit this bug report at https://bugs.php.net/bug.php?id=60940&edit=1
Bug #60679 [Opn->Nab]: FILEINFO_MIME_TYPE is not defined as a constant
Edit report at https://bugs.php.net/bug.php?id=60679&edit=1 ID: 60679 Updated by: il...@php.net Reported by:tomse at tomse dot dk Summary:FILEINFO_MIME_TYPE is not defined as a constant -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: FreeBSD 8.2 i386 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: 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. Cannot reproduce this issue... Previous Comments: [2012-01-07 11:11:49] tomse at tomse dot dk using FILEINFO_MIME gives no errors and works as intended. php / pecl was added with pkg_add -r from stable branch [2012-01-07 11:10:11] tomse at tomse dot dk Description: FILEINFO_MIME_TYPE is not defined as a constant error message when used with finfo_file(FILEINFO_MIME_TYPE, $string) it says something like this: "expected Int, string given" using 16 instead makes it work as should. -- Edit this bug report at https://bugs.php.net/bug.php?id=60679&edit=1
Bug #60574 [Opn->Nab]: range() returns array of integers when arguments are numeric strings
Edit report at https://bugs.php.net/bug.php?id=60574&edit=1
ID: 60574
Updated by: il...@php.net
Reported by:login dot naitsirch at arcor dot de
Summary:range() returns array of integers when arguments are
numeric strings
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2011-12-29 12:42:47] login dot naitsirch at arcor dot de
This is not clear enough, in my opinion.
Another question: Why should numeric strings be seen as integers and not as
strings?
[2011-12-29 01:16:14] hanskrentel at yahoo dot de
This is already documented:
4.1.0 to 4.3.2 In PHP versions 4.1.0 through 4.3.2, range() sees numeric
strings
as strings and not integers. Instead, they will be used for character
sequences.
For example, "4242" is treated as "4".
[2011-12-20 11:39:15] login dot naitsirch at arcor dot de
Description:
Hi.
I think the 'range()' function should return an array with strings, if the
'start' and 'limit' arguments are numeric strings. Otherwise it should be
mentioned in the documentation.
Test script:
---
string(1) "0"
[1]=> string(1) "1"
[2]=> string(1) "2"
[3]=> string(1) "3"
[4]=> string(1) "4"
[5]=> string(1) "5"
[6]=> string(1) "6"
[7]=> string(1) "7"
[8]=> string(1) "8"
[9]=> string(1) "9"
}
Actual result:
--
array(10) {
[0]=> int(0)
[1]=> int(1)
[2]=> int(2)
[3]=> int(3)
[4]=> int(4)
[5]=> int(5)
[6]=> int(6)
[7]=> int(7)
[8]=> int(8)
[9]=> int(9)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60574&edit=1
Bug #60668 [Opn->Nab]: Setting user_agent can send other headers
Edit report at https://bugs.php.net/bug.php?id=60668&edit=1 ID: 60668 Updated by: il...@php.net Reported by:vr...@php.net Summary:Setting user_agent can send other headers -Status: Open +Status: Not a bug Type: Bug Package:HTTP related Operating System: Irrelevant PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: 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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. It is up-to the developer to ensure that input supplied by the user is properly validated before being transmitted back to the user or external services. In this particular case the issue is input validation. You can do the same operation with any stream operation by feeding it user data. For example: $fp = fsockopen(web_server, 80); fwrite($fp, $user_input); ... Previous Comments: [2012-01-25 10:48:38] me at ktamura dot com vrana: I think this is a pretty bad security issue. Here is a proposed diff as a github gist: https://gist.github.com/1675788 [2012-01-06 10:08:41] vr...@php.net Description: Setting 'user_agent' INI value to a string containing a newline causes sending a new header. This behavior is even documented: http://php.net/wrappers.http#wrappers.http.example.custom.headers It is wrong for two reasons: 1. 'user_agent' INI setting should be used only for setting a User-Agent header and not for anything else. 2. It is a potential security risk (header injection) similar to the one fixed in PHP 5.1.2 (but with low impact). (See also bug #52979 but I believe that I am providing a better reasoning.) Test script: --- http://private/service.php'); ?> Expected result: Sending just a User-Agent header, not X-Command header. Actual result: -- Sending User-Agent and X-Command headers. If http://private/service.php accepts connections only from trusted sources and parses its commands from headers then it will execute the malicious action. -- Edit this bug report at https://bugs.php.net/bug.php?id=60668&edit=1
Bug #61230 [Opn->Nab]: stream_seek() is receiving SEEK_CUR on mode 'a' or 'a+'.
Edit report at https://bugs.php.net/bug.php?id=61230&edit=1 ID: 61230 Updated by: cataphr...@php.net Reported by:frame at dynamiccreated dot de Summary:stream_seek() is receiving SEEK_CUR on mode 'a' or 'a+'. -Status: Open +Status: Not a bug Type: Bug Package:Streams related Operating System: Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: seek is called to *determine* the current position. SEEK_CUR with offset 0 is used. There's no intention in changing the file pointer. This is expected behavior. Previous Comments: [2012-03-01 23:48:56] frame at dynamiccreated dot de Description: fopen() gives a wrong constant to stream_seek when opening the stream in append mode. Test script: --- SEEK_CUR (1) will be given. This is wrong since mode 'a' should set the pointer to the end of the file, so SEEK_END (2) would be right. #0 FileWrapper->stream_seek(0, 1) #1 fopen(xyz://test, a+) called at ... -- Edit this bug report at https://bugs.php.net/bug.php?id=61230&edit=1
[PHP-BUG] Bug #61268 [NEW]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
From: Operating system: solaris PHP version: 5.4.0 Package: Compile Failure Bug Type: Bug Bug description:--enable-dtrace leads make to clobber Zend/zend_dtrace.d Description: 5.4.0 bundle configured with only one option: --enable-dtrace The configure script runs fine and the build finishes without error. However, the next invocation of make (probably from trying to run 'make install') fails with the following error: [jack@fjpe6maa ~/php-5.4.0]$ make install gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o php_request_shutdown /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace185178.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 What's happening here is that make has determined that the file Zend/zend_dtrace.d is out of date and must be rebuilt. It matches a built-in implicit rule that ends up running: gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d This command fails with the error that you see, but it also clobbers zend_dtrace.d Here's a bit more detail from 'make -d': Prerequisite `/home/jack/php-5.4.0/Zend/zend_dtrace.d.o' is newer than target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Must remake target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Invoking builtin recipe to update target `/home/jack/php- 5.4.0/Zend/zend_dtrace.d'. gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Putting child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 on the chain. Live child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace187054.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o php_request_shutdown /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status Reaping losing child 80bdaa0 PID 5104 make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 I was able to work-around this issue by disabling built-in implicit rules with 'make -r'. Obviously, I had to recover the clobbered file before this worked. The offending Makefile may be seen here: http://harschsystems.com/bugs/php- 54_sol_dtrace/Makefile.txt For reference: On solaris (and solaris-derived) systems, the compilation of USDT dtrace probes goes something like this: $ dtrace -h -o foo_provider.h -s foo_provider.d >> Generates header file $ gcc -c foo_src.c $ dtrace -G -o foo_provider.o -s foo_provider.d foo_src.o >> Generates object file $ gcc -o a.out foo_provider.o foo_src.o For more detail, see: http://dtrace.org/blogs/dap/2011/12/13/usdt-providers- redux/ This test system is running an Illumos variant (derived from OpenSolaris). gmake 3.82 This bug deals with the same part of the build system as another bug I filed back in the 5.3 dev branch: https://bugs.php.net/bug.php?id=53338 As these were the only 2 times I've tried compiling php with dtrace, I'd say there should be better test coverage of solaris + --enable-dtrace. Expected result: make shouldn't delete source files Actual result: -- make deletes a source file, rendering the build system inoperable. -- Edit bug report at https://bugs.php.net/bug.php?id=61268&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61268&r=trysnapshot54 Try a snapshot (PHP 5.3):
Bug #60106 [Opn->Csd]: stream_socket_server + long unix socket path = 'Unknown error'
Edit report at https://bugs.php.net/bug.php?id=60106&edit=1
ID: 60106
Updated by: il...@php.net
Reported by:tyr...@php.net
Summary:stream_socket_server + long unix socket path =
'Unknown error'
-Status: Open
+Status: Closed
Type: Bug
Package:Streams related
Operating System: linux debian squeeze 64 bit
PHP Version:5.4.0beta2
-Assigned To:
+Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-03-03 20:36:07] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=323852
Log: Fixed bug #60106 (stream_socket_server silently truncates long unix socket
paths)
[2011-10-22 10:49:25] larue...@php.net
the limition is in socket self, not php, yes PHP can increase the limition, but
I
am afraid it dosen't work too.
but maybe we can throw warning when truncation occurring.
[2011-10-21 08:21:38] tyr...@php.net
I'm fine with the idea to mark this as a documentation problem, but maybe we
should change the length limit to something more common, like 127 or 255.
what do you think?
[2011-10-21 03:51:13] larue...@php.net
actullay, there is a limition,
sys/un.h
/* Structure describing the address of an AF_LOCAL (aka AF_UNIX) socket. */
struct sockaddr_un
{
__SOCKADDR_COMMON (sun_);
char sun_path[108]; /* Path name. */
};
I think this issue could mark as doc problem.
[2011-10-20 19:11:44] tyr...@php.net
Description:
this works:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a",
101);stream_socket_server("unix://".$file) && unlink($file);'
this isn't:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a",
102);stream_socket_server("unix://".$file) && unlink($file);'
gives me an:
Warning: stream_socket_server(): unable to connect to
unix:///tmp/
aa (Unknown error) in Command line code on line
1
I didn't found any mention in the documentation about restrictions on the
length
of the socket file.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60106&edit=1
Bug #61201 [Opn]: LOCK_EX in file_put_contents with custom streamwrapper fails
Edit report at https://bugs.php.net/bug.php?id=61201&edit=1
ID: 61201
Updated by: cataphr...@php.net
Reported by:s dot kleff at goalio dot de
Summary:LOCK_EX in file_put_contents with custom
streamwrapper fails
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Win7/64
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
LOCK_EX is currently only supported for regular files (except if FILE_APPEND is
used). This is due to the new opening mode 'c' added after bug #43182 that
presumably the stream wrappers written at that time wouldn't support. Your
script generates the following warning:
Warning: file_put_contents(): Exclusive locks may only be set for regular files
Although this works as designed, I think this should be revisited. I'll
reclassify this as request.
Previous Comments:
[2012-02-28 13:51:17] s dot kleff at goalio dot de
Description:
Currently I'm using a custom Streamwrapper for memcached access. The wrapper
works
fine unless I'm using the LOCK_EX parameter for file_put_contents.
If the parameter is given the function does neither write the file nor calls a
method of the streamwrapper. I included simple echo statements in all methods
of
the streamwapper but no output is shown.
I have done this because there is no documentation about which streamwrapper
methods are called during file_put_contents. I ASSUME that it should call
stream_lock like flock() does - but as mentioned before there is no output at
all.
Test script:
---
class MyWrapper {
// Assume other methods are implemented
// Just for demonstration
public function stream_lock($operation) {
echo "I've been called";
}
}
stream_register_wrapper('myWrapper, 'MyWrapper');
$result = file_put_contents('myWrapper://myFile','content',LOCK_EX);
echo $result;
Expected result:
true
(file is written)
Actual result:
--
false
(file is not written)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61201&edit=1
Bug #61253 [Asn]: Wrappers opened with errors concurrency problem
Edit report at https://bugs.php.net/bug.php?id=61253&edit=1 ID: 61253 Updated by: paj...@php.net Reported by:cataphr...@php.net Summary:Wrappers opened with errors concurrency problem Status: Assigned Type: Bug Package:Streams related Operating System: Any (ZTS) PHP Version:5.4SVN-2012-03-02 (SVN) -Assigned To:pajoye +Assigned To:mattficken Block user comment: N Private report: N New Comment: Matt, can you test this patch please? and add the test to our suites while being at it :) Previous Comments: [2012-03-02 22:13:36] cataphr...@php.net Pierre, please see if this fixes the problem. [2012-03-02 22:13:02] cataphr...@php.net The following patch has been added/updated: Patch Name: bug61253.diff Revision: 1330726381 URL: https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1330726381 [2012-03-02 22:08:08] cataphr...@php.net Description: When opening the same wrapper in several threads and this generates errors, a segfault may result. Test script: --- http://localhost/notfound'); Expected result: Each requests shows a 404 error. Actual result: -- Segfault given enough concurrency -- Edit this bug report at https://bugs.php.net/bug.php?id=61253&edit=1
