Bug #53508 [Opn]: Class not found caused by require_once
Edit report at http://bugs.php.net/bug.php?id=53508&edit=1 ID: 53508 User updated by:exsystemchina at gmail dot com Reported by:exsystemchina at gmail dot com Summary:Class not found caused by require_once Status: Open Type: Bug Package:Scripting Engine problem Operating System: Mac OS X 10.6 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: and something important i forgot to mention: THIS WILL ONLY HAPPEN WHEN RUNNING THE SCRIPT, everything's all right when debugging. Previous Comments: [2010-12-20 03:55:08] exsystemchina at gmail dot com no cacher is installed. [2010-12-20 03:34:25] ka...@php.net You don't happen to have any opcode cachers like APC installed? [2010-12-14 13:17:34] exsystemchina at gmail dot com //System.php //Utilities.php Just run System.php to see the fatal error with other classes before TObject loaded successfully inside System.php [2010-12-14 13:14:52] exsystemchina at gmail dot com ok, i have just know that a login is needed to download the zip file. now i have shorten the buggy code. [2010-12-13 10:18:21] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. 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 http://bugs.php.net/bug.php?id=53508 -- Edit this bug report at http://bugs.php.net/bug.php?id=53508&edit=1
[PHP-BUG] Req #53593 [NEW]: phpinfo() triggers system timezone warning
From: Operating system: Ubuntu 10.04 PHP version: 5.3.4 Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:phpinfo() triggers system timezone warning Description: phpinfo() should not output raw warning because: 1) it is redundant; the table already states: Default timezone America/New_York 2) phpinfo() is not a date/time function, even if it uses one internally; http://php.net/manual/en/function.date-default-timezone-set.php 3) the warning is emitted between rows of an HTML table, resulting in invalid markup Propose either suppressing the warning, or pretty printing it, so it doesn't break the layout. Test script: --- http://bugs.php.net/bug.php?id=53593&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53593&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53593&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53593&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53593&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53593&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53593&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53593&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53593&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53593&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53593&r=support Expected behavior: http://bugs.php.net/fix.php?id=53593&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53593&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53593&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53593&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53593&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53593&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53593&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53593&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53593&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53593&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53593&r=mysqlcfg
[PHP-BUG] Bug #53592 [NEW]: stream_socket_client uses NONBLOCK
From:
Operating system: CentOS 4.4
PHP version: 5.3.4
Package: Sockets related
Bug Type: Bug
Bug description:stream_socket_client uses NONBLOCK
Description:
stream_socket_enable_crypto() changes the stream to NONBLOCK before it
attempts
the encryption. I'm assuming this is so the timeout can be tracked, but
for
connections where the handshake doesn't work the process simply chews up
CPU while
the read() repeatedly EAGAIN fails and gettimeofday() is called.
Test script:
---
$stream = stream_socket_client("tcp://72.14.204.147:80", $errno, $errstr,
5);
stream_socket_enable_crypto($stream, TRUE,
STREAM_CRYPTO_METHOD_SSLv23_CLIENT);
Expected result:
For the socket to stay in blocked mode.
Actual result:
--
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("72.14.204.147")}, 16) = -1 EINPROGRESS (Operation now
in
progress)
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}], 1,
1000) =
1
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
select(4, [3], [3], [], {5, 0}) = 1 (out [3], left {5, 0})
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
--
Edit bug report at http://bugs.php.net/bug.php?id=53592&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53592&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53592&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53592&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53592&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53592&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53592&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53592&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53592&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53592&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53592&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53592&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53592&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53592&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53592&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53592&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53592&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53592&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53592&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53592&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53592&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53592&r=mysqlcfg
Req #34194 [Opn->Bgs]: Real properties in PHP classes
Edit report at http://bugs.php.net/bug.php?id=34194&edit=1
ID: 34194
Updated by: johan...@php.net
Reported by:stochnagara at hotmail dot com
Summary:Real properties in PHP classes
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
PHP Version:5CVS-2005-08-19 (CVS)
Block user comment: N
Private report: N
New Comment:
This request is covered by this RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Previous Comments:
[2005-08-19 16:41:21] stochnagara at hotmail dot com
Description:
I think that it would be nice to have real properties present in PHP. I
mean properties like those in C# but a little more flexible by allowing
getter and setter to have different visibility. See sample code below:
Reproduce code:
---
class person {
public $firstName, $lastName;
public getter fullName { // may also have ()
return "{$this->firstName} {$this->lastName}";
}
public setter fullName ($value) { // may also not have ($value) but a
special var.
list ($this->firstName, $this->lastName) = explode (' ', $value, 2);
}
}
$p = new person;
$p->fullName = "Foo bar";
echo $p->firstName . "\n";
echo $p->lastName . "\n";
echo $p->fullName . "\n";
Expected result:
Foo
bar
Foo bar
Actual result:
--
n/a
--
Edit this bug report at http://bugs.php.net/bug.php?id=34194&edit=1
Req #33894 [Opn->Bgs]: __MAIN_FILE__ constant
Edit report at http://bugs.php.net/bug.php?id=33894&edit=1
ID: 33894
Updated by: johan...@php.net
Reported by:marcos dot neves at gmail dot com
Summary:__MAIN_FILE__ constant
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: any
PHP Version:5.1.0b3
Block user comment: N
Private report: N
New Comment:
PHP_SELF is the best we can offer. Mind that the "main" file is not
always clear - think aboutauto_prepend_file/auto_append_file etc.
Previous Comments:
[2005-08-01 14:08:24] marcos dot neves at gmail dot com
$_SERVER['PHP_SELF'] hasn't the same value using php with apache and php
cli.
Run in a browser and as command line,
you'll see the difference.
At browser works fine do the follow:
if(__FILE__ == $_SERVER['PHP_SELF']) {
}
but does not work with cli.
Tested with PHP 5.1.0b3 on windows XP
[2005-08-01 13:28:51] der...@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. 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.
We've PHP_SELF for this.
[2005-07-27 23:27:50] marcos dot neves at gmail dot com
Description:
Today we have __FILE__ constant, that has the string fileName of the
current scrit. Would be nice a constant __MAIN_FILE__, wich has the file
name of the first requested PHP file.
So would be possible to do things like this, without use of external
library, and is interesting to everyone:
Reproduce code:
---
or used to include relative paths to an application, without define
constants
--
Edit this bug report at http://bugs.php.net/bug.php?id=33894&edit=1
Req #33893 [Opn->Csd]: $_SERVER['STARTUP_MICRO_TIME']
Edit report at http://bugs.php.net/bug.php?id=33893&edit=1 ID: 33893 Updated by: johan...@php.net Reported by:marcos dot neves at gmail dot com Summary:$_SERVER['STARTUP_MICRO_TIME'] -Status: Open +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: any PHP Version:5.1.0b3 -Assigned To: +Assigned To:johannes Block user comment: N Private report: N New Comment: In PHP trunk $_SERVER['REQUEST_TIME'] contains microsecond precision. Previous Comments: [2005-07-27 23:15:54] marcos dot neves at gmail dot com Description: $_SERVER['REQUEST_TIME'] is a very nice feature, But since many scripts runs in less than 0.1 seconds, would be nice exists a $_SERVER['STARTUP_MICRO_TIME'], so would be possible do something like below: Reproduce code: --- Expected result: A fine grained time elapse calculation Actual result: -- not perfect time elapse calculation -- Edit this bug report at http://bugs.php.net/bug.php?id=33893&edit=1
Req #33068 [Opn->Bgs]: Function declarations outside class struct
Edit report at http://bugs.php.net/bug.php?id=33068&edit=1
ID: 33068
Updated by: johan...@php.net
Reported by:john dot kraal at rse dot nl
Summary:Function declarations outside class struct
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Any
PHP Version:5.0.4
Block user comment: N
Private report: N
New Comment:
In C++ you'd have to add the declaration to the class and the separation
is needed for properly separating the implementation from the interface.
In PHP a more java-like approach was chosen.
Previous Comments:
[2005-05-19 17:08:51] john dot kraal at rse dot nl
changed my email.
[2005-05-19 17:07:19] john dot kraal at rse dot nl
Description:
It would be nice to have a C++ Style function declaration for classes
like this:
class example
{
var $blah;
function __construct()
{
$this->blah = 'test';
}
}
function example::returnBlah()
{
return $this->blah;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=33068&edit=1
Req #32746 [Opn->Bgs]: PHP command line option doesn't have verbose/debug output.
Edit report at http://bugs.php.net/bug.php?id=32746&edit=1 ID: 32746 Updated by: johan...@php.net Reported by:scott at abcoa dot com Summary:PHP command line option doesn't have verbose/debug output. -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: AIX or any Unix(s)/Linux(s) PHP Version:4.3.10 Block user comment: N Private report: N New Comment: Use a proper debugger like Xdebug. Previous Comments: [2005-04-18 17:50:38] scott at abcoa dot com Description: This is a request for enhancement for the command line option. I couldn't find an earlier bug report via bug search, so forgive me if this is a duplicate or something. As I looked up at http://us2.php.net/features.commandline and it doesn't have the option for debugging or verbose output via the shell environment. With most shell environment for bash, ksh, etc., I can do the -x or maybe -d option to see the output via the O/S and I/O so I can see what is goign on behind hte scene when I have problem with why am I not getting response. A line by line trace is useful also... Yes, I can do with exec() or system() but I had cURL compiled with PHP and other stuffs, so it get more complicated than it look. Thanks... Reproduce code: --- #!/usr/local/bin/php Expected result: Something like this or close enough, whatever make it possible for us to read the O/S output or I/O output... --snip-- -=[/usr/local/bin]==>sh -x ./inquiry_pull_test.sh + 0< l + = ./inquiry_pull_test.sh[3]: =: not found. + Testing Inquiry Send... * About to connect() to ec.equifax.com:443 * Connected to ec.equifax.com ((nil)) port 443 * SSL connection using RC4-MD5 * Server certificate: *subject: /C=US/ST=Georgia/L=Alpharetta/O=Equifax Inc/CN=ec.equifax.com *start date: 2004-07-01 02:57:28 GMT *expire date: 2005-07-01 02:57:28 GMT *common name: ec.equifax.com (matched) *issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/email=server-ce...@thawte.com > POST /servlet/stspost HTTP/1.1 Authorization: Basic blah blah OpenSSL/0.9.6g Host: ec.equifax.com Pragma: no-cache Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Content-Length: 396 Content-Type: application/x-www-form-urlencoded site_id=0&service_name=test&efx_request=DIAL blah blah --snip-- -- Edit this bug report at http://bugs.php.net/bug.php?id=32746&edit=1
Req #32332 [Opn->Bgs]: In safe mode, Authorization headers are not accesible
Edit report at http://bugs.php.net/bug.php?id=32332&edit=1 ID: 32332 Updated by: johan...@php.net Reported by:lacak at users dot sourceforge dot net Summary:In safe mode, Authorization headers are not accesible -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: ANY PHP Version:4.3.10 Block user comment: N Private report: N New Comment: This is a explicit security feature to avoid stealing authentication data on shared environments. Previous Comments: [2005-03-18 07:38:23] lacak at users dot sourceforge dot net if PHP is running as Apache module in safe_mode=On and I use "HTTP Digest Authorization", there is no possibility obtain supplied Authorization header. When I use apache_request_headers() function, Authorization header is not included (if safe_mode=On)! So I can not authenticate request. [2005-03-18 07:35:37] lacak at users dot sourceforge dot net if safe_mode=On there is no possibility to obtain HTTP Authorization header, so no validation can be make. The solution : why not include Authorization header in $_SERVER["Authorization"] ... ? Sample code : [2005-03-16 13:09:38] lacak at users dot sourceforge dot net Description: if PHP is running as Apache module in safe mode and I use "Digest Authorization", there is no possibility obtain supplied Authorization header. When I use apache_request_headers() function, Authorization header is not included ! So I can not authenticate request. -- Edit this bug report at http://bugs.php.net/bug.php?id=32332&edit=1
Req #32236 [Opn->Bgs]: Multiple paths for session.save_path
Edit report at http://bugs.php.net/bug.php?id=32236&edit=1 ID: 32236 Updated by: johan...@php.net Reported by:justin at redwiredesign dot com Summary:Multiple paths for session.save_path -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: FreeBSD 5. PHP Version:4.3.10 Block user comment: N Private report: N New Comment: Silently falling back to another location causes a performance impact and lead to non-deterministic behavior. It's better if the admin fixes the access rights properly Previous Comments: [2005-03-08 21:10:00] justin at redwiredesign dot com Description: In certain circumstances, there is the possibility that the directory referred to by session.save_path is non-writeable. It would be advantageous to be able to specify multiple paths on this line, colon-seperated like include_path so that when PHP tries to create a session file and fails, it has another location to create the file in. -- Edit this bug report at http://bugs.php.net/bug.php?id=32236&edit=1
Req #32135 [Opn->Bgs]: Add class_hierarchy() function
Edit report at http://bugs.php.net/bug.php?id=32135&edit=1 ID: 32135 Updated by: johan...@php.net Reported by:anferr at mecon dot gov dot ar Summary:Add class_hierarchy() function -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: it is trivial to create this from reflection. But you have to consider interfaces, too. For adding such a thing to the distribution the use cases are too limited. Previous Comments: [2005-02-28 18:51:04] anferr at mecon dot gov dot ar Description: It'll be very useful to add a class_hierarchy() function Proposed signature: array class_hierarchy(mixed $object) $object can be an object, or a string class name. returns an array with class hierarchy (ordered from obj to first parent, or reverse, but ordered :-) ) -- Edit this bug report at http://bugs.php.net/bug.php?id=32135&edit=1
Req #31838 [Opn->Bgs]: enable mysql transactions per session instead per script
Edit report at http://bugs.php.net/bug.php?id=31838&edit=1 ID: 31838 Updated by: johan...@php.net Reported by:php at zion-it dot com Summary:enable mysql transactions per session instead per script -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: redhat PHP Version:4.3.10 Block user comment: N Private report: N New Comment: This would at first be a feature request for the MySQL server to be ale to use a transaction with different connections as there is no way for PHP to guarantee that you hit the same web server child with the same connection again. Previous Comments: [2005-02-04 00:56:39] php at zion-it dot com Description: You should be able to keep a database connection open (like persistent connections) and execute transactions for mysql in another script for that specific mysql user and ip address. At the moment might apache create a new child process for a new http request and that makes it impossible to reuse the open database connection, because this new apache child process creates also a new database connection. The idea is that you can insert/delete/update in the mysql database and check the consequences in related scripts. When you do not like that, then you should be able to rollback and otherwise commit. Expected result: Full control of keeping database connections open and reuse them. -- Edit this bug report at http://bugs.php.net/bug.php?id=31838&edit=1
Req #30716 [Opn->Csd]: Dynamic Static Member Access
Edit report at http://bugs.php.net/bug.php?id=30716&edit=1
ID: 30716
Updated by: johan...@php.net
Reported by:jake at development dot mindvision dot com dot au
Summary:Dynamic Static Member Access
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Gentoo Linux (2.4.x)
PHP Version:5.0.1
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
"Dynamic static calls" were added in PHP 5.3.0
Previous Comments:
[2007-10-05 01:45:25] itisben at gmail dot com
Hi,
In case anyone is still beating their head against the wall -or-
doesn't want to use eval -or- isn't sure whether or not 5.2.4 fixed this
in addition to the dynamic static method call that was supposed to be
fixed in that version - http://bugs.php.net/bug.php?id=31318 (I can't
get it to work after moving to that version, unless the little note at
the bottom means that it is 5.3).
Anway, here it is - it requires PHP >=5 for the Reflection
getStaticPropertyValue($staticMemName);
...
?>
Hopefully the variable names are descriptive enough to get the general
idea.
Thanks,
Ben
[2005-12-21 00:23:58] jake at press dot id dot au
Heyas
I havent got a copy of php infront of me, and it has been many months
since i last poked around on this issue - so apologies if i am wrong...
But i dont beleive "call_user_func()" is the solution.
... we are trying too access a static member dynamically, not a static
method.
Such a pity, i have been successfully using a workaround along the same
lines as suggested by joscha at feth dot com for along time now, i was
hoping i could go thru and fix all of my code that is dependant on it by
now :(
I'll try and find some time too investigate this further and attempt to
fix - but i fear that will be closer to this time next year.
Jake Press
[2004-11-11 09:54:49] tony2...@php.net
use call_user_func() for that.
[2004-11-11 09:22:32] joscha at feth dot com
After I found out, that my note (http://news.php.net/php.notes/78312)
was deleted, which I thought was not a good idea, because it is the only
way to make a static function call to a "unknown" class, I wrote a Mail
to the guy who deleted it. After a few mails we decided that the code I
wrote in the note:
print_r(eval("return $classname::getBla();"));
is completely correct and working. So I resubmitted my note, but I also
think it'd be better to allow $classname::getBla(); out-of-the-box as
the eval call is always a performance killer and it restricts the use of
the code above to examples where no user-input is in $classname.
[2004-11-09 09:27:15] k at ailis dot de
Just for info: The problem is also present in latest CVS. And even if it
is not a bug it's still a useful feature request.
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
http://bugs.php.net/bug.php?id=30716
--
Edit this bug report at http://bugs.php.net/bug.php?id=30716&edit=1
Bug #53591 [Opn->Bgs]: exec() fails to impersonate calling context when fastcgi.impersonate is true
Edit report at http://bugs.php.net/bug.php?id=53591&edit=1 ID: 53591 Updated by: paj...@php.net Reported by:sbacsa at gmail dot com Summary:exec() fails to impersonate calling context when fastcgi.impersonate is true -Status: Open +Status: Bogus Type: Bug Package:IIS related Operating System: Windows Server 2008 PHP Version:5.3.4 Block user comment: N Private report: N New Comment: You have to give FCGI's php handler the permission to execute codes. Check out the IIS documentation (as far as I remember it is also documented in the PHP manual, in the IIS configuration part). Previous Comments: [2010-12-22 00:10:41] sbacsa at gmail dot com Description: It appears that enabling fastcgi.impersonate on Windows in PHP 5.3.x does not actually impersonate the calling user when using exec() or similar. I would just get messages saying "Cannot fork", whereas in PHP 5.2.x there was no such error. Turning off fastcgi.impersonate fixed this issue, as IIS seems to run PHP in the user context of the worker process anyway. Test script: --- http://bugs.php.net/bug.php?id=53591&edit=1
[PHP-BUG] Bug #53591 [NEW]: exec() fails to impersonate calling context when fastcgi.impersonate is true
From: Operating system: Windows Server 2008 PHP version: 5.3.4 Package: IIS related Bug Type: Bug Bug description:exec() fails to impersonate calling context when fastcgi.impersonate is true Description: It appears that enabling fastcgi.impersonate on Windows in PHP 5.3.x does not actually impersonate the calling user when using exec() or similar. I would just get messages saying "Cannot fork", whereas in PHP 5.2.x there was no such error. Turning off fastcgi.impersonate fixed this issue, as IIS seems to run PHP in the user context of the worker process anyway. Test script: --- http://bugs.php.net/bug.php?id=53591&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53591&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53591&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53591&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53591&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53591&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53591&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53591&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53591&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53591&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53591&r=support Expected behavior: http://bugs.php.net/fix.php?id=53591&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53591&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53591&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53591&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53591&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53591&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53591&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53591&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53591&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53591&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53591&r=mysqlcfg
Bug #53556 [Opn->Fbk]: cURL returns wrong Content-Length after a redirect to a page without CL-header
Edit report at http://bugs.php.net/bug.php?id=53556&edit=1 ID: 53556 Updated by: il...@php.net Reported by:michael dot moench at marktjagd dot de Summary:cURL returns wrong Content-Length after a redirect to a page without CL-header -Status: Open +Status: Feedback Type: Bug Package:HTTP related Operating System: Ubuntu 10.04 PHP Version:5.3SVN-2010-12-16 (SVN) Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2010-12-16 18:24:03] cataphr...@php.net This looks like a problem upstream. [2010-12-16 13:27:22] michael dot moench at marktjagd dot de Description: I have an URL which will redirect me to a second, final URL. The first response contains a Content-Length-Header, the second does not. If I set the CURLOPT_FOLLOWLOCATION option, I would expect that the "download_content_length"-field from curl_getinfo contains the Content-Length of the final URL, in this case 0, but it contains the Content-Length of the first Response. The first Response: HTTP/1.1 302 Found Date: Thu, 16 Dec 2010 11:39:31 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Location: http://productdata.download.affili.net/xxx Set-Cookie: ASP.NET_SessionId=xxx; path=/; HttpOnly Cache-Control: private Content-Type: text/html; charset=Windows-1252 Content-Length: 214 The Second Response: HTTP/1.1 200 OK Date: Thu, 16 Dec 2010 11:39:32 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Content-Disposition: attachment; filename=xxx.gz Transfer-Encoding: chunked Cache-Control: private Content-Type: application/gzip -- Edit this bug report at http://bugs.php.net/bug.php?id=53556&edit=1
Bug #53588 [Csd->Bgs]: SplMinHeap bad insert sort
Edit report at http://bugs.php.net/bug.php?id=53588&edit=1
ID: 53588
Updated by: cataphr...@php.net
Reported by:ojousset49 at yahoo dot fr
Summary:SplMinHeap bad insert sort
-Status: Closed
+Status: Bogus
Type: Bug
Package:SPL related
Operating System: RHEL 55 64bits
PHP Version:5.3.4
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
Reverted change and closing as bogus.
Turns out the semantics of SplMinHeap::compare() and
SplMaxHeap::compare() are different. See:
http://docs.php.net/manual/en/splminheap.compare.php
http://docs.php.net/manual/en/splmaxheap.compare.php
Previous Comments:
[2010-12-21 18:29:29] cataphr...@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/.
Thank you for the report, and for helping us make PHP better.
[2010-12-21 18:29:16] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=306542
Log: - Fixed bug #53588 (SplMinHeap bad sorting with custom compare
function).
[2010-12-21 14:50:45] ojousset49 at yahoo dot fr
Description:
SplMinHeap have the same behavior than SplMaxHeap when inserting data.
Top value of a SplMinHeap object is the max value instead of the min
Test script:
---
class MySimpleHeap extends SplMinHeap{
public function compare( $value1, $value2 ){
return ( $value1 - $value2 );
}
}
$obj = new MySimpleHeap();
$obj->insert( 8 );
$obj->insert( 0 );
$obj->insert( 4 );
foreach( $obj as $number ) {
echo $number."\n";
}
// Output display : 8, 4, 0 instead of 0, 4, 8
--
Edit this bug report at http://bugs.php.net/bug.php?id=53588&edit=1
Req #30139 [Opn]: Link phpinfo() modules to manual
Edit report at http://bugs.php.net/bug.php?id=30139&edit=1
ID: 30139
Updated by: johan...@php.net
Reported by:phpbugs at everythingbuffy dot com
Summary:Link phpinfo() modules to manual
Status: Open
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:PHP options/info functions
Operating System: XP Home
PHP Version:5.0.1
Block user comment: N
Private report: N
New Comment:
It is not that easy as PHP extensions might come from third party
sources. This requires extending the module_entry structure.
(zend_extions interestingly provide this functionality ...)
Previous Comments:
[2004-09-18 16:34:06] phpbugs at everythingbuffy dot com
Description:
To make it easier to find information for items enabled in the PHP build
why not link the output of phpinfo() to the specific manual pages?
This would be easy to achieve, as follows:
In /ext/standard/info.c change line 70 from:
php_printf("%s\n", module->name,
module->name);
To:
php_printf("http://www.php.net/%s\";
title=\"%s\">%s\n", module->name, module->name, module->name);
Thank you
Sean :)
--
Edit this bug report at http://bugs.php.net/bug.php?id=30139&edit=1
Req #27022 [Opn]: Class constant has no visibility modificator
Edit report at http://bugs.php.net/bug.php?id=27022&edit=1
ID: 27022
Updated by: johan...@php.net
Reported by:and...@php.net
Summary:Class constant has no visibility modificator
Status: Open
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:Scripting Engine problem
Operating System: *
PHP Version:5CVS-2004-01-23 (dev)
Block user comment: N
Private report: N
New Comment:
Proper category.
Previous Comments:
[2004-01-27 16:05:24] he...@php.net
it is a feature request.
[2004-01-27 15:59:16] sni...@php.net
Isn't this more of a feature request?
[2004-01-23 12:47:45] and...@php.net
Description:
It is not possible to use visibility modificator like
public/protected/private on a class constant.
Reproduce code:
---
php -r "class fubar { protected const some_const = 123; }"
Actual result:
--
PHP Parse error: parse error, unexpected T_CONST, expecting T_VARIABLE
in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=27022&edit=1
Req #24252 [Opn->Bgs]: Problem with session_set_save_handler() when connecting to db outside of obj
Edit report at http://bugs.php.net/bug.php?id=24252&edit=1
ID: 24252
Updated by: johan...@php.net
Reported by:jpenn at cheetah-soft dot com
Summary:Problem with session_set_save_handler() when
connecting to db outside of obj
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: RHAT 7
PHP Version:4.3.1
Block user comment: N
Private report: N
New Comment:
This can't be done in another way. There are multiple factors affecting
this. For instance session.auto-start might start a session before the
actual script runs. Then there's the whole shutdown order chicken and
egg problem: what should be shutdown first - global variables or
sessions? - If sessions first: What happens to destructors trying to
access sessions. if variables first - well, you see it, the session
can't access the connection.
Previous Comments:
[2003-09-14 23:14:31] jpenn at cheetah-soft dot com
Anyone know what the actuall status of this is. I see that the category
was changed to 'feature request', not really sure why.
Is this an internal problem with ZE1?
~ Thanks
[2003-07-09 11:09:20] jpenn at cheetah-soft dot com
sniper - sorry for the personal insults, no harm meant. Problem is, what
you just explained as 'full but short' - that is exactly what was posted
- without the opening and closing php tags.
Problem is you can't cut and paste this code as it will not work. If you
are testing this you will need the entire class to do the testing as
without all six (6) of the arg's, the session_set_save_handler() will
not work at all. So, to get what this bug is, you will need the class
itself, which can be found at this address:
http://www.cheetah-soft.com/csh/
Download the class and set up something temporary for it. Once you have
the class as downloaded, it will run fine.
After you have it running, move the db connection outside of the class
and you will see the bug.
Thanks
[2003-07-09 10:55:53] sni...@php.net
Please leave the personal insults out.
You still don't seem to understand what "full but short" script means so
I'll try and explain it simply:
1. It starts with
2. I can copy'n'paste it from this report to a file and run
without having to edit it / add to it
3. It contains ONLY the necessary lines which show the problem
Clear now?
[2003-07-09 10:51:05] jpenn at cheetah-soft dot com
What do you want sniper. Do you want the whole 300 lines of code from
the session handler?
[2003-07-09 10:40:03] jpenn at cheetah-soft dot com
[quote]
As long as you fail to provide a full, but short example script which
CLEARLY shows whatta hell you're talking about, this stays bogus.
[/quote]
What in gods name are you talking about? Do you not see in the 4th post
on this bug? That is as clear as it gets. Are you a kid or something
sniper? This is rediculous that you are popping in and out of this and
totally overlooking the posts on this bug.
[From 4th post in this bug]
session_set_save_handler( array( &$this, 'open' ), array( &$this,
'close' ), array( &$this, 'read' ), array( &$this, 'write' ), array(
&$this, 'destroy' ), array( &$this, 'gc' ) );
Now, this is the open method:
function open( $blah, $blah )
{
$res = mysql_connect( 'blah', 'blah', 'blah' );
mysql_select_db( 'blah', $res );
return( true );
}
Do you not see that? Do you want it emailed to you?
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
http://bugs.php.net/bug.php?id=24252
--
Edit this bug report at http://bugs.php.net/bug.php?id=24252&edit=1
Req #25887 [Opn->Csd]: session.save_path should respect open_basedir
Edit report at http://bugs.php.net/bug.php?id=25887&edit=1 ID: 25887 Updated by: johan...@php.net Reported by:john at scl dot co dot uk Summary:session.save_path should respect open_basedir -Status: Open +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: linux PHP Version:4.3.3 -Assigned To: +Assigned To:johannes Block user comment: N Private report: N New Comment: This is the case meanwhile Previous Comments: [2003-10-16 11:24:41] john at scl dot co dot uk Description: Surely either: session.save_path should respect open_basedir OR (but not so good) session.save_path should be a php_admin_value rather than just a php_value as at present. With proper configuration one can then prevent session hijacking. -- Edit this bug report at http://bugs.php.net/bug.php?id=25887&edit=1
Req #24087 [Opn->Csd]: Make temporary_directory available in userland
Edit report at http://bugs.php.net/bug.php?id=24087&edit=1
ID: 24087
Updated by: johan...@php.net
Reported by:philip at cornado dot com
Summary:Make temporary_directory available in userland
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: all
PHP Version:5CVS-2003-06-08 (dev)
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
sys_get_temp_dir() was introduced in 5.2.1
Previous Comments:
[2003-06-19 09:54:25] phi...@php.net
My initial reason is upload_tmp_dir does not provide a value unless it's
explicitly set, I need this information before sending a file (for a
nice debugging tool that will help the masses). On the contrary,
session.tmp_path does provide its value regardless of it being
explicitly set or not so that's a weird inconsistency among directive
behavior. Anyway, knowing TEMPORARY_DIRECTORY will solve my problem
although 'fixing' upload_tmp_dir will also solve it.
Either way, get_temporary_directory() will need to be called before a
file is uploaded, I don't think it is currently.
[2003-06-09 02:49:54] der...@php.net
I don't really see the use of this. Why would this be useful?
[2003-06-08 22:33:05] philip at cornado dot com
How about making the result from get_temporary_directory() available in
user land, most likely as a constant named TEMPORARY_DIRECTORY This
would be useful in that we'd know where this is, in both Windows and
*nix. The code that defines the internal variable temporary_directory
is here:
http://lxr.php.net/source/php4/main/php_open_temporary_file.c#164
I'm not a devel guy, but the following hack seems mildly appropriate:
REGISTER_STRING_CONSTANT("TEMPORARY_DIRECTORY",
get_temporary_directory(), strlen(get_temporary_directory()), 0);
Not sure where to put it though, or if it's fully correct (doubtful),
but please consider this idea as it would be nice.
One *possible* concern is security but I think it's worth it, *maybe*
disable this option in safe_mode. It's not like the TEMP directory is a
big secret, nor is viewing various related directives like
session.save_path and upload_tmp_dir.
--
Edit this bug report at http://bugs.php.net/bug.php?id=24087&edit=1
Req #24072 [Opn->Bgs]: 4.3.2 Clean Install Win Installer issues
Edit report at http://bugs.php.net/bug.php?id=24072&edit=1 ID: 24072 Updated by: johan...@php.net Reported by:stratguitar at mindspring dot com Summary:4.3.2 Clean Install Win Installer issues -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Windows 2000 Pro PHP Version:4.3.2 Block user comment: N Private report: N New Comment: with the "new" installer this should be way better now. Previous Comments: [2003-06-07 16:28:17] stratguitar at mindspring dot com Sorry to be so persistent - but there IS no place in the php.ini to correct the path for PEAR. So why is phpinfo() reading it as php4\pear, and where is it reading it from, if not from php4ts.dll? I assure you it is not in the ini file anywhere. No offense intended, truly, all of you developers are stunning. But until a php.ini (or php.ini-dist) is supplied with each install that reflects more than 'examples' for a newer user, this is going to be hard to figure out. To me (as a QA Team Leader for a national software product), this is, while not technically a bug in the program, a bug in the documentation/supplied setup materials for new users. While I do not suppose that phpinfo.php is written to reflect every system variable, it would be good to know why the cgi_force_redirect parameters are not reflected in the phpinfo.php. I apologize for being so stuffy about this, but QA is my life. The ini should contain all the info needed to get up and running, or, if the system is reflecting configuration (the Pear stuff) that is drawn from elsewhere in the system, then the user needs to know why. Close this, if you like, but I strongly disagree with this, even if its a Tier3 bug. :D It's still a bug. [2003-06-07 04:42:55] sni...@php.net You're supposed to set those in php.ini, not bug. [2003-06-06 20:13:41] stratguitar at mindspring dot com Excuse me - addionally, all 3 of the reported install issues (saying 4.3.0 in error), should have been attributed to 4.3.2, not just the issue with the php4\pear path. [2003-06-06 20:03:48] stratguitar at mindspring dot com Exactly. I misrepresented the version in the body of my text, but you'll see (apologetically) that the version to which I was referring was not 4.3.0, but. 4.3.2. A quite thorough search of the bug reports did not result in my finding this issue. I am therefore reopening this issue; I don't believe it is bogus. Check the php4ts.dll and you'll see that what I'm saying is still an issue. Apologies again for this error on my part - I just installed 4.3.2 yesterday; CLEAN. No earlier version on my computer anywhere; complete reformat and reinstall of Win2K prior to install of 4.3.2 [2003-06-06 18:30:47] sni...@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. PHP 4.3.2 was released already.. 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 http://bugs.php.net/bug.php?id=24072 -- Edit this bug report at http://bugs.php.net/bug.php?id=24072&edit=1
Req #23612 [Opn->Bgs]: new "Security" related settings
Edit report at http://bugs.php.net/bug.php?id=23612&edit=1 ID: 23612 Updated by: johan...@php.net Reported by:dale at daledude dot com Summary:new "Security" related settings -Status: Open +Status: Bogus Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: linux rh 7.2 PHP Version:4.3.2RC2 Block user comment: N Private report: N New Comment: open_basedir is quite close to your request. Previous Comments: [2003-05-13 10:23:24] dale at daledude dot com I posted this as a response to bug #22410, but taking a chance to open it as a new feature request. How about a virtual chroot, if you will, within php.ini and httpd.conf (needed per vhost). I hacked suexec for perl scripts to *actually* chroot to the vhosts directory tree. Needless to say this meant hardlinking required libs and executables to the vhosts directory tree, but was easy after creating a template directory tree to hardlink to. In the case of mod_php it would need to be a "fake" or internal chroot except for ticks, exec, system, etc calls where it can be safe to do an actual chroot() call since the external process will die off and the mod_php environment left in tact. Here is a proposal of new settings... * chroot_basedir: All file operations are relative to this. Not including ticks, system, exec, dl, etc. Example (pseudo): php_admin_value chroot_basedir = /home/virtual/domain.com The fopen would actually try to open "/home/virtual/domain.com/var/www/html/file.php". This might cause some overhead per function call. As I haven't even started to look at the best way to implement it I'm just guessing. Maybe the fopen arg can be manipulated the same place open_basedir is checked? * chroot_execdir: Jail to be in for ticks, exec, system, dl, etc. Follows same premise as chroot_basedir. Spawn a process chroot'd to this directory then execute the external command. Same way suexec does basically. I am considering implementing the above. No idea where to start just yet. I *very* briefly fgrep'd php source for occurances of open_basedir to get a quick glimpse. Please contact me with remarks. -- Edit this bug report at http://bugs.php.net/bug.php?id=23612&edit=1
Req #21353 [Opn->Bgs]: Functions for using references
Edit report at http://bugs.php.net/bug.php?id=21353&edit=1
ID: 21353
Updated by: johan...@php.net
Reported by:aulbach at ssilk dot de
Summary:Functions for using references
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
PHP Version:4.3.0
Block user comment: N
Private report: N
New Comment:
foreach ( $array as &$value )
is implemented
references_unset() / references_all() would require a massive re-design
as we don't have proper global variable lists. Use of references is
discouraged anyways.
Previous Comments:
[2003-01-02 15:22:59] aulbach at ssilk dot de
In my opinion there are some functions missing in PHP, depending the
handling of references. I found out, that it isn't possible to find out,
if and what other variables references to my value. But this is
sometimes important, especially for very complex scripts or
self-configuring.
So I would suggest the following new functions:
- references() (or perhaps better references_of() which is more
meaningful) - returns an array of all referenced variables, exept the
current. false, if it has no other references
print_r( references($b) );
should output "array('a')", this means $b has in it's local and/or
global scope the reference $a.
Hm, maybe it's important to differ local and global, so a second
parameter with the defined values REFERENCES_LOCAL etc. Could be fine.
Maybe it's difficult to output referenced variables which are objects or
arrays... I have currently no idea how to do that consequently and
easy:
$a=array(0=>1);
$b=&$a[0];
print_r(references($b));
... should output what?? array('a'=>array('0')) or array('a[0]')??
(btw: In the case of the second option the following feature would be
very nice (I have been missing this sometimes, but don't know if this is
currently working):
$c='a[0]';
$$c='hugo';
echo $a[0];
-> outputs 'hugo' )
- references_all() (or perhaps better all_references() ?)- This is like
references(), but returns ALL references, including the parameter. So it
should return always an array. This is good to build a loop here, see
down.
- is_referenced() or perhaps referenced_num() - returns true or better
the number of references of this variable to the VALUE (without counting
itself)
$a=1;
$b=&$a;
echo referenced_num($a);
echo referenced_num($b);
should both output '1'
- unset_references() - unsets all references to the VALUE of a variable,
with this you can be sure, that storage of this value is cleaned up,
even, if you are in a local scope like
function bla() {
global $a;
unset_references($a);
}
$a='hugo'
bla();
# $a is unset
This is not the very same as setting the VALUE to the value NULL
($a=null;), where the references to $a will survive.
It really unsets all references to the value unsets, it is just like it
has never been set before, which means, that
unset_references($a);
echo $b;
(should consequently output a notice, that $b never has been set in the
script...)
A gimmick to be consequent unset_references(&$var) should be the same as
unset($var) and deletes only the REFERENCE $var.
Indeed
unset_references($a);
is maybe the same (?) as:
foreach ( all_references($a) as $v ) {
unset_references(&$$v);
}
Looks very cool. :-)
Another good name alias would be unset_value(), cause it also unsets the
value, or more simply clean() or purge().
- There may be some other features depending references, like
foreach ( $array as &$value )
which will call the loop var $value by reference instead by value (think
this could be easy to implement).
- The documentation should be rewritten in some parts. My experience
brought out, that it's fine to distinguish better between
* VARIABLE (= *always* a REFERENCE, or POINTER to a VALUE, unlike C, PHP
cannot directly hold VALUES in a VARIABLE)
and
* VALUE (= STORAGEPLACE of a VARIABLE, a VALUE can have many VARIABLES
or REFERENCES)
The documentation here is based on PHP3, in PHP4 many things has
changed, so it's a little "wrong" in some parts (see my comment to the
function unset())...
This would make many things more clearly for beginners - I saw this with
our trainees here: When I explained, that a variable is always only a
reference to a value they said all "ah, ja, that is it, this is missing
in the docs"... :-)
--
Edit this bug report at http://bugs.php.net/bug.php?id=21353&edit=1
Req #21155 [Opn->Bgs]: Macro Request
Edit report at http://bugs.php.net/bug.php?id=21155&edit=1
ID: 21155
Updated by: johan...@php.net
Reported by:james at grickle dot org
Summary:Macro Request
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Slackware-current (12/22/02)
PHP Version:4.2.3
Block user comment: N
Private report: N
New Comment:
For errors you could use trigger_error89 plus an error handler. Having a
"pre processor" for the "PHP Hypertext Preprocessor" doesn't have many
benefits besides complexity.
Some people were experimenting with
http://pecl.php.net/package/PreProcessor or build systems (ant, phing,
...) doing such substitutions, though. But nothing proved to be useful.
Previous Comments:
[2003-04-27 09:41:45] james at grickle dot org
__LINE__ and __FILE__ were just meant to be used as an example of how a
macro feature might be used
I intended it to be more of a preprocessor. So where ever it sees:
DOERR(FATAL,"Database Error..");
it would replace it with
errOut(FATAL, __FILE__ . ': ' . __LINE__ . ': ' . "Database
Error..");
So __FILE__ and __LINE__ would actually be in the file and line the
macro would be at. Using it much in the same way as the C preprocessor
is/can be used.
[2003-04-26 09:44:55] he...@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.
Maybe it would, but that is not the way __FILE__ and __LINE__ work.
Simply use them as they are now: They always return the current file and
line - no more no less.
[2002-12-22 22:45:39] james at grickle dot org
Hello,
I would like to request something along the lines of macros. It would
help a lot when you need to run __LINE__ and/or __FILE__ constants
through a function.
A simplified version of what I'd need them for. Currently I have:
errOut([severity], [message]);
Every time I use errOut I have __FILE__ and __LINE__ in the message:
define(FATAL, 7);
errOut(FATAL, __FILE__ . ": " . __LINE__ . ": Database error bla bla
bla");
It could be shortened up by something like this:
mdefine("DOERR", "errOut($1, __FILE__ . ': ' . __LINE__ . ': ' . $2)");
DOERR(FATAL,"Database Error bla bla bla");
This could be used for more vital things than that of course. Anything
along those lines would be great.
Thank You,
James Harr
--
Edit this bug report at http://bugs.php.net/bug.php?id=21155&edit=1
Req #19694 [Opn->Bgs]: Persistent Global Variable
Edit report at http://bugs.php.net/bug.php?id=19694&edit=1
ID: 19694
Updated by: johan...@php.net
Reported by:citd at mediaways dot net
Summary:Persistent Global Variable
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: N/A
PHP Version:4.2.3
Block user comment: N
Private report: N
New Comment:
PHP has a shared-nothing architecture on purpose. Adding global
variables introduces locking issues, issues when scaling to multiple
machines etc. apc_store()/apc_fetch() or memcache as well as others
provide solutions depending on your environment and needs.
Previous Comments:
[2004-09-07 19:38:13] ras...@php.net
By the way, if it is just read-only config file key/value type stuff you
are worried about, you can use cfg_get_var() to read custom .ini
directives that will only be read on startup. With the new
--with-config-file-scan-dir mechanism you can even configure a directory
that will be scanned for ini files, so every application that needs
config entries can simply drop their config ini file in that dir and the
configuration will be read once on server startup.
[2004-09-07 17:39:35] ras...@php.net
The various opcode caches tend to implement this. mmcache and ZPS have
ways to do this easily. And I will be submitting a patch to pecl/apc to
support this as well shortly. That is, you can do:
$var = apc_fetch('var');
And:
apc_store('var',$var);
We definitely don't want PHP to require a standalone marshalling process
as someone suggested and as someone else suggested, no, the $_SESSION
code is nothing like what would be needed for this.
The main argument against using something like this is that your
horizontal scalability is destroyed if you use it incorrectly. Ideally
you want to architect your solution such that every request is sandboxed
from every other so that you can handle an entire browsing session on
any of dozens of servers behind a load balancer, for example. If you
store state on a single machine like this, much like many Java apps do
by storing state in the JVM, then you have a scalability nightmare on
your hands.
[2004-09-07 15:50:17] jon_obuchowski at terc dot edu
I agree that a persistent variable functionality would
be useful; however, this does require an additional
level of configuration to allow ISPs soem leeway in how
this is deployed;
a) availabilty of feature AT ALL determined by
configuration
b) separate scopes for different applications (as
several may be running on the same server and there
needs to be some way to prevent collision); these
scopes may be determined by name (low inter-application
security), automatically by domain/URL path (higher
security) or by some other means
c) timeout periods (i.e. how often the application
variables need to be refreshed) need to be determined
on a per-server, per-application basis
d) some sort of locking mechanism to prevent corruption
issues during writing (assuming that multiple
concurrent PHP requests have similar shared-memory
issues to concurrent threads); this could be automatic
and/or manual, depending on performance needs...
[2004-03-26 14:17:13] hans at deragon dot biz
2004 and still nothing showing up for this issue. I am a newbie, but
even I (less than one month of PHP experience) understand the importance
of this issue. One could do something with shared memory and msession,
but these solutions are overkill for small projects (and shared memory
does not work on Windows). What we need is a simple global array named
$_PERSISTENT. Anything stored in this array lives until unset or the
server goes down.
And as for the implementation, can't this be done easily? I mean,
$_SESSION exists already and the only difference between $_SESSION and
$_PERSISTENT is that $_SESSION is associated with a session (cookie or
URL based). Just reuse the same code for $_SESSION, but without the
user association code and voilà , a new feature is born.
$_PERSISTENT would be so intuitive to use to newbies, as $_SESSION is.
[2003-02-20 12:29:50] okapi at yahoo dot com
I'm suprised why something along these lines isn't incorporated into PHP
such that there's an application process that could handle application
scope variables (and query caching). It seems this kind of issue would
make it match up better with ASP and Cold Fusion. Is anyone aware of
such an effort?
---
Bug #53586 [Opn->Bgs]: parent::__construct destroys object if exception is thrown
Edit report at http://bugs.php.net/bug.php?id=53586&edit=1
ID: 53586
Updated by: cataphr...@php.net
Reported by:peters at yandex dot ru
Summary:parent::__construct destroys object if exception is
thrown
-Status: Open
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
This is a proper, safe way to handle the exception. The exception in a
constructor means the object is likely not in a valid state after it.
PHP itself doesn't require parent constructors to be called and, if
they're called and there's an exception, it allows catching the
exception. In my opinion this a bad choice, but for internal objects
it's much worse because the consequences of an internal object in an
invalid state are segfaults and other problems.
Closing as bogus.
Previous Comments:
[2010-12-21 10:03:55] peters at yandex dot ru
Description:
When calling parent::__construct() in any(!) method of PDO successor
class and exception is thrown in parent::__construct() successor object
is destroyed regardless of the fact that exception is properly caught.
Test script:
---
class B extends PDO
{
public function __construct()
{
try
{
parent::__construct('');
}
catch (Exception $e)
{
}
var_dump($this);
}
}
new B('');
Expected result:
object(B)#45 (0) { }
Actual result:
--
NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=53586&edit=1
Req #53589 [Opn->Bgs]: Certain Ports do not work properly on fsockopen
Edit report at http://bugs.php.net/bug.php?id=53589&edit=1
ID: 53589
Updated by: cataphr...@php.net
Reported by:acesjunk at yahoo dot com
Summary:Certain Ports do not work properly on fsockopen
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:PHP options/info functions
Operating System: Windows XP SP3
PHP Version:5.3.4
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.
Please see the manual page for long2ip
Previous Comments:
[2010-12-21 15:10:12] acesjunk at yahoo dot com
Description:
---
>From manual page: http://www.php.net/function.fsockopen#See Also
---
When fsocketopen is used to check if a socket is open, it returns true
always on udp, which what I am trying to do is see if a server is up,
this Example will always be true, no matter what, becuase I think it
detects the port if it is open, rather check if it is in use. See Test
Script...
Test script:
---
Server 1';
echo '';
}else{
echo 'Server 1';
echo '';
fclose($sv1);
}
?>
Expected result:
I expect for the truth of the port being open or closed. So if server is
down, then it should say server 1 Offline. But if the Server is up,
then it should say the server is online. This all is being reported
onto a webpage. www.aceintergraphs.com! I used this before without the
UDP part for a different server, and different port, which worked
perfectly, but with this port 27910 for a game called Quake2, it does
not work! I was trying to find alternate methods and means to do this,
but with failure. I searched your site up and down, and was unable to
find a solution without having to do massive php coding. I would like
to keep things simple, not complicated! This is going directly to my
webpage, so it can not be too complex, or it will reduce load times for
my site.
Actual result:
--
Server always shows as online, or offline when it is really online or
offline!
--
Edit this bug report at http://bugs.php.net/bug.php?id=53589&edit=1
Req->Bug #53588 [Asn->Csd]: SplMinHeap bad insert sort
Edit report at http://bugs.php.net/bug.php?id=53588&edit=1
ID: 53588
Updated by: cataphr...@php.net
Reported by:ojousset49 at yahoo dot fr
Summary:SplMinHeap bad insert sort
-Status: Assigned
+Status: Closed
-Type: Feature/Change Request
+Type: Bug
Package:SPL related
Operating System: RHEL 55 64bits
PHP Version:5.3.4
Assigned To:cataphract
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-12-21 18:29:16] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=306542
Log: - Fixed bug #53588 (SplMinHeap bad sorting with custom compare
function).
[2010-12-21 14:50:45] ojousset49 at yahoo dot fr
Description:
SplMinHeap have the same behavior than SplMaxHeap when inserting data.
Top value of a SplMinHeap object is the max value instead of the min
Test script:
---
class MySimpleHeap extends SplMinHeap{
public function compare( $value1, $value2 ){
return ( $value1 - $value2 );
}
}
$obj = new MySimpleHeap();
$obj->insert( 8 );
$obj->insert( 0 );
$obj->insert( 4 );
foreach( $obj as $number ) {
echo $number."\n";
}
// Output display : 8, 4, 0 instead of 0, 4, 8
--
Edit this bug report at http://bugs.php.net/bug.php?id=53588&edit=1
Bug #53587 [Opn]: "Seek error: Invalid argument" when creating ZIP larger than 2GB on 32bit arch
Edit report at http://bugs.php.net/bug.php?id=53587&edit=1
ID: 53587
User updated by:jerome dot auge at anakeen dot com
Reported by:jerome dot auge at anakeen dot com
Summary:"Seek error: Invalid argument" when creating ZIP
larger than 2GB on 32bit arch
Status: Open
Type: Bug
-Package:*Compression related
+Package:Zip Related
Operating System: Linux, Mac OS X
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Package: "Zip Related"
Previous Comments:
[2010-12-21 11:23:30] jerome dot auge at anakeen dot com
Description:
On 32bit system, you can't generate ZIP files larger than 2GB.
I reproduce this with :
- PHP 5.3.4 on Mac OS 10.5 i686
Also observed with :
- PHP 5.2.4 on Ubuntu 8.04 i686
- PHP 5.3.2 on Ubuntu 10.04 i686
I tested with 3 files of 1GB random data. After adding the 3 files, the
$zip-
>close() returns the error "Seek error: Invalid argument" and there is
no zip
output file.
After looking into ext/zip, it seems that the problem is in the use of
"unsigned
long" types instead of the "off_t" type in zip_cdir struct, and the fact
that
the HAVE_FSEEKO and HAVE_FTELLO are not detected/defined by the
./configure
script.
On OS X (PHP 5.3.4), if I recompile the ext/zip extension by hand with
the patch
below (force HAVE_FSEEKO/HAVE_FTELLO and adjust the "unsigned long" to
"off_t"
in zip_cdir struct), then I can create my ZIP archive larger than 2GB.
Test script:
---
#!/bin/bash
# -- Create 3 files of 1GB random data
for I in 1 2 3; do dd if=/dev/urandom of=f$I bs=1M count=1024; done
# -- Create a 'out.zip' archive containing these 3 files
php -r '$zip = new ZipArchive(); $zip->open("out.zip",
ZIPARCHIVE::CREATE); $zip->addFile("f1"); $zip->addFile("f2");
$zip->addFile("f3"); $ret = $zip->close(); if( $ret === false ) { print
sprintf("Error: %s", $zip->getStatusString()); };'
zip -T out.zip
if [ $? -ne 0 ]; then
echo "ERROR"
exit 1
fi
echo "OK"
exit 0
Expected result:
A ZIP archive with a size around 3GB that passes the `zip -T'
verification.
Actual result:
--
$zip->close() returns false with error "Seek error: Invalid argument",
and the ZIP
output file is not produced.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53587&edit=1
[PHP-BUG] Req #53589 [NEW]: Certain Ports do not work properly on fsockopen
From:
Operating system: Windows XP SP3
PHP version: 5.3.4
Package: PHP options/info functions
Bug Type: Feature/Change Request
Bug description:Certain Ports do not work properly on fsockopen
Description:
---
>From manual page: http://www.php.net/function.fsockopen#See Also
---
When fsocketopen is used to check if a socket is open, it returns true
always on udp, which what I am trying to do is see if a server is up, this
Example will always be true, no matter what, becuase I think it detects the
port if it is open, rather check if it is in use. See Test Script...
Test script:
---
Server 1';
echo '';
}else{
echo 'Server 1';
echo '';
fclose($sv1);
}
?>
Expected result:
I expect for the truth of the port being open or closed. So if server is
down, then it should say server 1 Offline. But if the Server is up, then
it should say the server is online. This all is being reported onto a
webpage. www.aceintergraphs.com! I used this before without the UDP part
for a different server, and different port, which worked perfectly, but
with this port 27910 for a game called Quake2, it does not work! I was
trying to find alternate methods and means to do this, but with failure. I
searched your site up and down, and was unable to find a solution without
having to do massive php coding. I would like to keep things simple, not
complicated! This is going directly to my webpage, so it can not be too
complex, or it will reduce load times for my site.
Actual result:
--
Server always shows as online, or offline when it is really online or
offline!
--
Edit bug report at http://bugs.php.net/bug.php?id=53589&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53589&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53589&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53589&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53589&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53589&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53589&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53589&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53589&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53589&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53589&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53589&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53589&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53589&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53589&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53589&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53589&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53589&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53589&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53589&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53589&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53589&r=mysqlcfg
[PHP-BUG] Req #53588 [NEW]: SplMinHeap bad insert sort
From:
Operating system: RHEL 55 64bits
PHP version: 5.3.4
Package: SPL related
Bug Type: Feature/Change Request
Bug description:SplMinHeap bad insert sort
Description:
SplMinHeap have the same behavior than SplMaxHeap when inserting data.
Top value of a SplMinHeap object is the max value instead of the min
Test script:
---
class MySimpleHeap extends SplMinHeap{
public function compare( $value1, $value2 ){
return ( $value1 - $value2 );
}
}
$obj = new MySimpleHeap();
$obj->insert( 8 );
$obj->insert( 0 );
$obj->insert( 4 );
foreach( $obj as $number ) {
echo $number."\n";
}
// Output display : 8, 4, 0 instead of 0, 4, 8
--
Edit bug report at http://bugs.php.net/bug.php?id=53588&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53588&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53588&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53588&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53588&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53588&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53588&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53588&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53588&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53588&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53588&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53588&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53588&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53588&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53588&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53588&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53588&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53588&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53588&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53588&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53588&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53588&r=mysqlcfg
Bug #53303 [Bgs]: x86_64 PHP needs libjpeg and libpng i686 ?
Edit report at http://bugs.php.net/bug.php?id=53303&edit=1 ID: 53303 User updated by:sites at evoluons dot net Reported by:sites at evoluons dot net Summary:x86_64 PHP needs libjpeg and libpng i686 ? Status: Bogus Type: Bug Package:Compile Failure Operating System: Fedora 14 x86_64 PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Sincerely, I don't understand... If lib64 directory is not useful, why PHP found all libraries into lib64, but not only jpeg and png ? There is a reason to that ? Why all others libraries where found, and worked ? Thank you ;) Previous Comments: [2010-12-21 12:56:16] paj...@php.net As it was explained many times in various reports, we can't write fixes for broken distributions. Please report this bug upstream so they can finally get rid of lib64 (or do it correctly). [2010-12-21 12:54:51] sites at evoluons dot net I already said I can't use --with-libdir=lib64 because PHP don't find MySQL libs with that option... Why PHP found all libs into lib64 except for libjpeg and libpng ? [2010-12-21 12:48:12] paj...@php.net You can use the lib prefix configure option for the broken linux distribution that still uses the lib64 directory. [2010-12-21 12:43:32] sites at evoluons dot net I tried with new PHP 5.3.4 and same problem : My Fedora 14 is x86_64 only, and PHP search jpeg and png libs into /usr/lib rather into /usr/lib64 The only "good" solution I found is to create 2 sym links : ln -s /usr/lib64/libjpeg.so /usr/lib/libjpeg.so ln -s /usr/lib64/libpng.so /usr/lib/libpng.so After, it works. Please, can you fix it ? Thank you ;) [2010-11-16 08:14:21] sites at evoluons dot net Maybe nobody had that bug ? 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 http://bugs.php.net/bug.php?id=53303 -- Edit this bug report at http://bugs.php.net/bug.php?id=53303&edit=1
Bug #53303 [Bgs]: x86_64 PHP needs libjpeg and libpng i686 ?
Edit report at http://bugs.php.net/bug.php?id=53303&edit=1 ID: 53303 Updated by: paj...@php.net Reported by:sites at evoluons dot net Summary:x86_64 PHP needs libjpeg and libpng i686 ? Status: Bogus Type: Bug Package:Compile Failure Operating System: Fedora 14 x86_64 PHP Version:5.3.4 Block user comment: N Private report: N New Comment: As it was explained many times in various reports, we can't write fixes for broken distributions. Please report this bug upstream so they can finally get rid of lib64 (or do it correctly). Previous Comments: [2010-12-21 12:54:51] sites at evoluons dot net I already said I can't use --with-libdir=lib64 because PHP don't find MySQL libs with that option... Why PHP found all libs into lib64 except for libjpeg and libpng ? [2010-12-21 12:48:12] paj...@php.net You can use the lib prefix configure option for the broken linux distribution that still uses the lib64 directory. [2010-12-21 12:43:32] sites at evoluons dot net I tried with new PHP 5.3.4 and same problem : My Fedora 14 is x86_64 only, and PHP search jpeg and png libs into /usr/lib rather into /usr/lib64 The only "good" solution I found is to create 2 sym links : ln -s /usr/lib64/libjpeg.so /usr/lib/libjpeg.so ln -s /usr/lib64/libpng.so /usr/lib/libpng.so After, it works. Please, can you fix it ? Thank you ;) [2010-11-16 08:14:21] sites at evoluons dot net Maybe nobody had that bug ? [2010-11-13 08:44:57] sites at evoluons dot net The only workaround I found is to use --with-libdir=lib64 because it prevent to user MySQL library (compiled by myself) but if I create 2 sym links from /usr/lib64/libjpeg.so to /usr/lib/libjpeg.so and /usr/lib64/libpng.so to /usr/lib/libpng.so it work. I think I am not the only one to obtain that... maybe a better solution that symbolic links ? 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 http://bugs.php.net/bug.php?id=53303 -- Edit this bug report at http://bugs.php.net/bug.php?id=53303&edit=1
Bug #53303 [Bgs]: x86_64 PHP needs libjpeg and libpng i686 ?
Edit report at http://bugs.php.net/bug.php?id=53303&edit=1 ID: 53303 User updated by:sites at evoluons dot net Reported by:sites at evoluons dot net Summary:x86_64 PHP needs libjpeg and libpng i686 ? Status: Bogus Type: Bug Package:Compile Failure Operating System: Fedora 14 x86_64 PHP Version:5.3.4 Block user comment: N Private report: N New Comment: I already said I can't use --with-libdir=lib64 because PHP don't find MySQL libs with that option... Why PHP found all libs into lib64 except for libjpeg and libpng ? Previous Comments: [2010-12-21 12:48:12] paj...@php.net You can use the lib prefix configure option for the broken linux distribution that still uses the lib64 directory. [2010-12-21 12:43:32] sites at evoluons dot net I tried with new PHP 5.3.4 and same problem : My Fedora 14 is x86_64 only, and PHP search jpeg and png libs into /usr/lib rather into /usr/lib64 The only "good" solution I found is to create 2 sym links : ln -s /usr/lib64/libjpeg.so /usr/lib/libjpeg.so ln -s /usr/lib64/libpng.so /usr/lib/libpng.so After, it works. Please, can you fix it ? Thank you ;) [2010-11-16 08:14:21] sites at evoluons dot net Maybe nobody had that bug ? [2010-11-13 08:44:57] sites at evoluons dot net The only workaround I found is to use --with-libdir=lib64 because it prevent to user MySQL library (compiled by myself) but if I create 2 sym links from /usr/lib64/libjpeg.so to /usr/lib/libjpeg.so and /usr/lib64/libpng.so to /usr/lib/libpng.so it work. I think I am not the only one to obtain that... maybe a better solution that symbolic links ? [2010-11-13 07:22:04] sites at evoluons dot net I tried with --with-libdir=lib64 and now MySQL libraries are not found... so it's not a good solution. 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 http://bugs.php.net/bug.php?id=53303 -- Edit this bug report at http://bugs.php.net/bug.php?id=53303&edit=1
Bug #53303 [Opn->Bgs]: x86_64 PHP needs libjpeg and libpng i686 ?
Edit report at http://bugs.php.net/bug.php?id=53303&edit=1 ID: 53303 Updated by: paj...@php.net Reported by:sites at evoluons dot net Summary:x86_64 PHP needs libjpeg and libpng i686 ? -Status: Open +Status: Bogus Type: Bug Package:Compile Failure Operating System: Fedora 14 x86_64 PHP Version:5.3.4 Block user comment: N Private report: N New Comment: You can use the lib prefix configure option for the broken linux distribution that still uses the lib64 directory. Previous Comments: [2010-12-21 12:43:32] sites at evoluons dot net I tried with new PHP 5.3.4 and same problem : My Fedora 14 is x86_64 only, and PHP search jpeg and png libs into /usr/lib rather into /usr/lib64 The only "good" solution I found is to create 2 sym links : ln -s /usr/lib64/libjpeg.so /usr/lib/libjpeg.so ln -s /usr/lib64/libpng.so /usr/lib/libpng.so After, it works. Please, can you fix it ? Thank you ;) [2010-11-16 08:14:21] sites at evoluons dot net Maybe nobody had that bug ? [2010-11-13 08:44:57] sites at evoluons dot net The only workaround I found is to use --with-libdir=lib64 because it prevent to user MySQL library (compiled by myself) but if I create 2 sym links from /usr/lib64/libjpeg.so to /usr/lib/libjpeg.so and /usr/lib64/libpng.so to /usr/lib/libpng.so it work. I think I am not the only one to obtain that... maybe a better solution that symbolic links ? [2010-11-13 07:22:04] sites at evoluons dot net I tried with --with-libdir=lib64 and now MySQL libraries are not found... so it's not a good solution. [2010-11-13 07:18:41] sites at evoluons dot net On a forum, someone tells we must use "--with-libdir=lib64" onto 64 bits systems. OK, but why, freetype, mcrypt etc... automatically use lib64 without it, and libjpeg and libpng not ? I admit I don't understand ;) 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 http://bugs.php.net/bug.php?id=53303 -- Edit this bug report at http://bugs.php.net/bug.php?id=53303&edit=1
Bug #53303 [Opn]: x86_64 PHP needs libjpeg and libpng i686 ?
Edit report at http://bugs.php.net/bug.php?id=53303&edit=1 ID: 53303 User updated by:sites at evoluons dot net Reported by:sites at evoluons dot net Summary:x86_64 PHP needs libjpeg and libpng i686 ? Status: Open Type: Bug Package:Compile Failure Operating System: Fedora 14 x86_64 -PHP Version:5.3.3 +PHP Version:5.3.4 Block user comment: N Private report: N New Comment: I tried with new PHP 5.3.4 and same problem : My Fedora 14 is x86_64 only, and PHP search jpeg and png libs into /usr/lib rather into /usr/lib64 The only "good" solution I found is to create 2 sym links : ln -s /usr/lib64/libjpeg.so /usr/lib/libjpeg.so ln -s /usr/lib64/libpng.so /usr/lib/libpng.so After, it works. Please, can you fix it ? Thank you ;) Previous Comments: [2010-11-16 08:14:21] sites at evoluons dot net Maybe nobody had that bug ? [2010-11-13 08:44:57] sites at evoluons dot net The only workaround I found is to use --with-libdir=lib64 because it prevent to user MySQL library (compiled by myself) but if I create 2 sym links from /usr/lib64/libjpeg.so to /usr/lib/libjpeg.so and /usr/lib64/libpng.so to /usr/lib/libpng.so it work. I think I am not the only one to obtain that... maybe a better solution that symbolic links ? [2010-11-13 07:22:04] sites at evoluons dot net I tried with --with-libdir=lib64 and now MySQL libraries are not found... so it's not a good solution. [2010-11-13 07:18:41] sites at evoluons dot net On a forum, someone tells we must use "--with-libdir=lib64" onto 64 bits systems. OK, but why, freetype, mcrypt etc... automatically use lib64 without it, and libjpeg and libpng not ? I admit I don't understand ;) [2010-11-13 07:00:46] sites at evoluons dot net My ./configure is : ./configure --with-apxs2=/usr/local/apache_maxou/bin/apxs --with-config-file-path=/usr/local/apache_maxou/conf --disable-ipv6 --with-gd --with-zlib --enable-ftp --enable-sockets --with-curl --enable-mbstring --enable-exif --without-pdo-sqlite --without-sqlite --without-pear --enable-zip --prefix=/usr/local/php_maxou --with-mysql=/usr/local/mysql --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-mcrypt Thank you ;) 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 http://bugs.php.net/bug.php?id=53303 -- Edit this bug report at http://bugs.php.net/bug.php?id=53303&edit=1
[PHP-BUG] Bug #53587 [NEW]: "Seek error: Invalid argument" when creating ZIP larger than 2GB on 32bit arch
From:
Operating system: Linux, Mac OS X
PHP version: 5.3.4
Package: *Compression related
Bug Type: Bug
Bug description:"Seek error: Invalid argument" when creating ZIP larger than
2GB on 32bit arch
Description:
On 32bit system, you can't generate ZIP files larger than 2GB.
I reproduce this with :
- PHP 5.3.4 on Mac OS 10.5 i686
Also observed with :
- PHP 5.2.4 on Ubuntu 8.04 i686
- PHP 5.3.2 on Ubuntu 10.04 i686
I tested with 3 files of 1GB random data. After adding the 3 files, the
$zip-
>close() returns the error "Seek error: Invalid argument" and there is no
zip
output file.
After looking into ext/zip, it seems that the problem is in the use of
"unsigned
long" types instead of the "off_t" type in zip_cdir struct, and the fact
that
the HAVE_FSEEKO and HAVE_FTELLO are not detected/defined by the ./configure
script.
On OS X (PHP 5.3.4), if I recompile the ext/zip extension by hand with the
patch
below (force HAVE_FSEEKO/HAVE_FTELLO and adjust the "unsigned long" to
"off_t"
in zip_cdir struct), then I can create my ZIP archive larger than 2GB.
Test script:
---
#!/bin/bash
# -- Create 3 files of 1GB random data
for I in 1 2 3; do dd if=/dev/urandom of=f$I bs=1M count=1024; done
# -- Create a 'out.zip' archive containing these 3 files
php -r '$zip = new ZipArchive(); $zip->open("out.zip", ZIPARCHIVE::CREATE);
$zip->addFile("f1"); $zip->addFile("f2"); $zip->addFile("f3"); $ret =
$zip->close(); if( $ret === false ) { print sprintf("Error: %s",
$zip->getStatusString()); };'
zip -T out.zip
if [ $? -ne 0 ]; then
echo "ERROR"
exit 1
fi
echo "OK"
exit 0
Expected result:
A ZIP archive with a size around 3GB that passes the `zip -T' verification.
Actual result:
--
$zip->close() returns false with error "Seek error: Invalid argument", and
the ZIP
output file is not produced.
--
Edit bug report at http://bugs.php.net/bug.php?id=53587&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53587&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53587&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53587&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53587&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53587&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53587&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53587&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53587&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53587&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53587&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53587&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53587&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53587&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53587&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53587&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53587&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53587&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53587&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53587&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53587&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53587&r=mysqlcfg
Bug #53585 [Fbk->Bgs]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1 ID: 53585 Updated by: paj...@php.net Reported by:serge dot sitnikov at gmail dot com Summary:PNG support broken, Abort trap: 6 (core dumped) -Status: Feedback +Status: Bogus Type: Bug Package:GD related Operating System: FreeBSD 8.1-RELEASE PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Then it is definitively not a PHP problem. The tests suite work just fine, and all PNGs I use for testing as well (from the PNG tests suite and some other). Please report the issue to FreeBSD or update it as suggested in the other comment. Previous Comments: [2010-12-21 10:48:03] serge dot sitnikov at gmail dot com @paj...@php.net You may test on that image, for example: http://upload.wikimedia.org/wikipedia/commons/7/7a/Basketball.png [2010-12-21 10:40:54] serge dot sitnikov at gmail dot com @paj...@php.net Image does not matter. Any PNG image I have tested lead to the same result -- core dumped. Already tested that on two machines. [2010-12-21 10:25:30] paj...@php.net @serge dot sitnikov at gmail dot com Please provide the PNG image you use as test. [2010-12-21 10:24:38] paj...@php.net Not a php problem then :) [2010-12-21 09:26:55] serge dot sitnikov at gmail dot com Unfortunately, upgrading and reinstalling all of PHP related ports does not solve the problem. 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 http://bugs.php.net/bug.php?id=53585 -- Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1 ID: 53585 Comment by: serge dot sitnikov at gmail dot com Reported by:serge dot sitnikov at gmail dot com Summary:PNG support broken, Abort trap: 6 (core dumped) Status: Feedback Type: Bug Package:GD related Operating System: FreeBSD 8.1-RELEASE PHP Version:5.3.4 Block user comment: N Private report: N New Comment: @paj...@php.net You may test on that image, for example: http://upload.wikimedia.org/wikipedia/commons/7/7a/Basketball.png Previous Comments: [2010-12-21 10:40:54] serge dot sitnikov at gmail dot com @paj...@php.net Image does not matter. Any PNG image I have tested lead to the same result -- core dumped. Already tested that on two machines. [2010-12-21 10:25:30] paj...@php.net @serge dot sitnikov at gmail dot com Please provide the PNG image you use as test. [2010-12-21 10:24:38] paj...@php.net Not a php problem then :) [2010-12-21 09:26:55] serge dot sitnikov at gmail dot com Unfortunately, upgrading and reinstalling all of PHP related ports does not solve the problem. [2010-12-21 08:49:52] eugene at krivoruchko dot info In FreeBSD 8.0 After update all port: #portmanager -u This problem resolved... 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 http://bugs.php.net/bug.php?id=53585 -- Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1
ID: 53585
Comment by: serge dot sitnikov at gmail dot com
Reported by:serge dot sitnikov at gmail dot com
Summary:PNG support broken, Abort trap: 6 (core dumped)
Status: Feedback
Type: Bug
Package:GD related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
@paj...@php.net
Image does not matter. Any PNG image I have tested lead to the same
result --
core dumped. Already tested that on two machines.
Previous Comments:
[2010-12-21 10:25:30] paj...@php.net
@serge dot sitnikov at gmail dot com
Please provide the PNG image you use as test.
[2010-12-21 10:24:38] paj...@php.net
Not a php problem then :)
[2010-12-21 09:26:55] serge dot sitnikov at gmail dot com
Unfortunately, upgrading and reinstalling all of PHP related ports does
not solve
the problem.
[2010-12-21 08:49:52] eugene at krivoruchko dot info
In FreeBSD 8.0
After update all port:
#portmanager -u
This problem resolved...
[2010-12-21 08:18:20] serge dot sitnikov at gmail dot com
Description:
PNG support broken, completely. If PHP runs under Apache that will lead
to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
Bug #53585 [Bgs->Fbk]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1
ID: 53585
Updated by: paj...@php.net
Reported by:serge dot sitnikov at gmail dot com
Summary:PNG support broken, Abort trap: 6 (core dumped)
-Status: Bogus
+Status: Feedback
Type: Bug
Package:GD related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
@serge dot sitnikov at gmail dot com
Please provide the PNG image you use as test.
Previous Comments:
[2010-12-21 10:24:38] paj...@php.net
Not a php problem then :)
[2010-12-21 09:26:55] serge dot sitnikov at gmail dot com
Unfortunately, upgrading and reinstalling all of PHP related ports does
not solve
the problem.
[2010-12-21 08:49:52] eugene at krivoruchko dot info
In FreeBSD 8.0
After update all port:
#portmanager -u
This problem resolved...
[2010-12-21 08:18:20] serge dot sitnikov at gmail dot com
Description:
PNG support broken, completely. If PHP runs under Apache that will lead
to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
Bug #53585 [Opn->Bgs]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1
ID: 53585
Updated by: paj...@php.net
Reported by:serge dot sitnikov at gmail dot com
Summary:PNG support broken, Abort trap: 6 (core dumped)
-Status: Open
+Status: Bogus
Type: Bug
Package:GD related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Not a php problem then :)
Previous Comments:
[2010-12-21 09:26:55] serge dot sitnikov at gmail dot com
Unfortunately, upgrading and reinstalling all of PHP related ports does
not solve
the problem.
[2010-12-21 08:49:52] eugene at krivoruchko dot info
In FreeBSD 8.0
After update all port:
#portmanager -u
This problem resolved...
[2010-12-21 08:18:20] serge dot sitnikov at gmail dot com
Description:
PNG support broken, completely. If PHP runs under Apache that will lead
to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
[PHP-BUG] Bug #53586 [NEW]: parent::__construct destroys object if exception is thrown
From:
Operating system: Linux
PHP version: 5.3.4
Package: PDO related
Bug Type: Bug
Bug description:parent::__construct destroys object if exception is thrown
Description:
When calling parent::__construct() in any(!) method of PDO successor class
and exception is thrown in parent::__construct() successor object is
destroyed regardless of the fact that exception is properly caught.
Test script:
---
class B extends PDO
{
public function __construct()
{
try
{
parent::__construct('');
}
catch (Exception $e)
{
}
var_dump($this);
}
}
new B('');
Expected result:
object(B)#45 (0) { }
Actual result:
--
NULL
--
Edit bug report at http://bugs.php.net/bug.php?id=53586&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53586&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53586&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53586&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53586&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53586&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53586&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53586&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53586&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53586&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53586&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53586&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53586&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53586&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53586&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53586&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53586&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53586&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53586&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53586&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53586&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53586&r=mysqlcfg
Req #49461 [Com]: parse_ini_file: semicolon in section header
Edit report at http://bugs.php.net/bug.php?id=49461&edit=1
ID: 49461
Comment by: wangyi6854 at sohu dot com
Reported by:sebastian dot schleussner at angstrom dot uu dot se
Summary:parse_ini_file: semicolon in section header
Status: Bogus
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
How can I get right result with get_browser()? The function can't take
'INI_SCANNER_RAW' like parameter.
Previous Comments:
[2010-12-20 13:27:45] j...@php.net
See the 3rd (optional) parameter to parse_ini_file(), INI_SCANNER_RAW is
used internally for the browscap stuff.
[2009-09-09 06:45:14] sebastian dot schleussner at angstrom dot uu dot
se
Just tried the second part of your suggestion, oc3ans. Here's another
inconsistency.
A *key* with an escaped semicolon is *ignored* in PHP 5.2.10.
But in PHP 5.3.0 it causes the parsing to quit silently - it does not
fail as with unescaped semicolons in sections, and returns the lines
before the "malformed" one, but does not read any further.
[2009-09-09 06:30:02] sebastian dot schleussner at angstrom dot uu dot
se
Okay, classification as "bug" may be debatable, and note that I have
made this a "Feature/Change Request".
At the very least, it is an undocumented and irritating change of
functionality.
Next, it is a change that breaks normal parsing of the widely used
browscaps.ini, which PHP's own get_browser still reads flawlessly.
Most importantly, semicolons ARE allowed inside quotes, and I think it
is very logical to interpret the square brackets of section titles as
quoting, too (as pre-5.3 PHP did). There is no legitimate use of a
semicolon *for starting a comment* before the closing square bracket, so
there is no reason to interpret it as such. If one wants to add a
comment on the title line, one can do so after the closing bracket.
As to accepted standards: On the one hand my experience is that there is
a lot of variation in the format of INI files, so a parser should be
reasonably lenient. On the other hand I have never seen backslash
escaping in INI files and I'm not at all sure it is part of any
"accepted standard" for them.
It only works partly anyway, and inconsistently.
Take this file:
;sample3.ini
[a\;b];c
x=y\;z
y="a;b"
z="a\;b"
and run print_r(parse_ini_file("sample3.ini", true));
You get (PHP 5.2.10 and 5.3.0):
Array
(
[a\;b] => Array
(
[x] => y\
[y] => a;b
[z] => a\;b
)
)
No bailout, but (a) the backslash remains inside title and quotes, (b)
the escaping does not work in values. No good, IMHO.
Variable z shows that titles and quoted strings are still considered
equally in terms of backslashes, and x demos that unquoted ;'s are
always filtered, but while the unescaped ; in y is allowed, it's not in
the title in 5.3 -- that's inconsistent and should be reverted.
I rest my case.
[2009-09-09 05:40:48] oc3ans at gmail dot com
According to accepted standards of ini files the semicolon is starting a
comment that lasts till the end of the line, so IMHO this is not a bug,
if you want to include semicolons in the keys or sections you should
escape it with a backslash.
[2009-09-03 20:17:37] sebastian dot schleussner at angstrom dot uu dot
se
Description:
This is a follow-up to Bug #49443.
The character breaking parse_ini_file of PHP 5.3.0 with browscap.ini is
actually the comment character ";" inside section headers - not one of
the special characters.
Reproduce code:
---
;sample1.ini
; demonstration of what works in 5.2 and 5.3
[a(b){c}&~![^]
x=y
;sample2.ini
; demonstration of the problem
[a;b];c
x=y
Code:
-
Expected result:
As in PHP 5.2.10 -- the header's square brackets being interpreted as
quoting:
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
Array
(
[a;b] => Array
(
[x] => y
)
)
Actual result:
--
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
PHP Warning: syntax error, unexpected $end, expecting ']' in
sample2.ini on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=49461&edit=1
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1
ID: 53585
Comment by: serge dot sitnikov at gmail dot com
Reported by:serge dot sitnikov at gmail dot com
Summary:PNG support broken, Abort trap: 6 (core dumped)
Status: Open
Type: Bug
Package:GD related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Unfortunately, upgrading and reinstalling all of PHP related ports does
not solve
the problem.
Previous Comments:
[2010-12-21 08:49:52] eugene at krivoruchko dot info
In FreeBSD 8.0
After update all port:
#portmanager -u
This problem resolved...
[2010-12-21 08:18:20] serge dot sitnikov at gmail dot com
Description:
PNG support broken, completely. If PHP runs under Apache that will lead
to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
