Bug #55009 [Com]: Error when compile
Edit report at http://bugs.php.net/bug.php?id=55009&edit=1 ID: 55009 Comment by: hexes at mail dot ru Reported by:hexes at mail dot ru Summary:Error when compile Status: Closed Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 Assigned To:thekid Block user comment: N Private report: N New Comment: «But early i always you this» i'm sorry, should be: «But early i always use this» Previous Comments: [2011-06-14 05:50:06] hexes at mail dot ru 2 the...@php.net: That's good, but i think (Of course, I tried to use it) that trouble with compilation not only in lib path. I had changed config.m4, but when i compile it again i again get this message, and compilation braked. I couldn't use last snapshot (as you advise me in bug #55022) because i use only packages from portage (Gentoo). You say that "It doesn't look like this has anything to do with PHP." But early i always you this files (will attache it) and everything was ok. [2011-06-13 10:46:35] the...@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. [2011-06-13 10:45:58] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312117 Log: - MFH suppression of compiler warning noted in bug #55009 [2011-06-13 10:45:24] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312116 Log: - MFH suppression of compiler warning noted in bug #55009 [2011-06-13 10:43:23] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312115 Log: - Fix compiler warning about long vs. int in printf() # See bug #55009 # Compare to _server_message_handler() a little below, where this # is done the same way 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=55009 -- Edit this bug report at http://bugs.php.net/bug.php?id=55009&edit=1
Bug #55022 [Com]: memory_limit exhausted when set charset in sybase_connect
Edit report at http://bugs.php.net/bug.php?id=55022&edit=1 ID: 55022 Comment by: hexes at nail dot ru Reported by:hexes at mail dot ru Summary:memory_limit exhausted when set charset in sybase_connect Status: Feedback Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Maybe I wrote it is not clear, just clarify: if i delete it (at here i mean if i delete 'cp1251' from connect string), script work correct, except message: Sybase: Server message: Character set conversion is not available between client character set 'utf8' and server character set 'cp1251'. (severity 11, procedure N/A) Result return only one row, that couldn't exhaust 156353484 bytes... Previous Comments: [2011-06-11 03:15:52] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2011-06-11 03:15:17] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=312044 Log: - Possible fix for bug #55022 (memory_limit exhausted when set charset in sybase_connect) [2011-06-10 10:28:05] hexes at mail dot ru Description: The same script, the same query if i set sybase_connect($this->server_name, $this->login, $this->pass, 'cp1251') i get Allowed memory size of 134217728 bytes exhausted (tried to allocate 156353484 bytes) if i delete it, script work correct, except message: Sybase: Server message: Character set conversion is not available between client character set 'utf8' and server character set 'cp1251'. (severity 11, procedure N/A) Result return only one row, that couldn't exhaust 156353484 bytes... -- Edit this bug report at http://bugs.php.net/bug.php?id=55022&edit=1
Bug #55009 [Com]: Error when compile
Edit report at http://bugs.php.net/bug.php?id=55009&edit=1 ID: 55009 Comment by: hexes at mail dot ru Reported by:hexes at mail dot ru Summary:Error when compile Status: Closed Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 Assigned To:thekid Block user comment: N Private report: N New Comment: 2 the...@php.net: That's good, but i think (Of course, I tried to use it) that trouble with compilation not only in lib path. I had changed config.m4, but when i compile it again i again get this message, and compilation braked. I couldn't use last snapshot (as you advise me in bug #55022) because i use only packages from portage (Gentoo). You say that "It doesn't look like this has anything to do with PHP." But early i always you this files (will attache it) and everything was ok. Previous Comments: [2011-06-13 10:46:35] the...@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. [2011-06-13 10:45:58] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312117 Log: - MFH suppression of compiler warning noted in bug #55009 [2011-06-13 10:45:24] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312116 Log: - MFH suppression of compiler warning noted in bug #55009 [2011-06-13 10:43:23] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312115 Log: - Fix compiler warning about long vs. int in printf() # See bug #55009 # Compare to _server_message_handler() a little below, where this # is done the same way [2011-06-13 10:32:19] the...@php.net The "$SYBASE_CT_INCDIR/libsybct.so" issue was fixed by SVN rev 311917 in bug Bug #53540. $ svn up ext/sybase_ct/config.m4 At revision 312114. $ grep libsybct ext/sybase_ct/config.m4 elif test -f $SYBASE_CT_LIBDIR/libsybct64.so && test $PHP_SYBASE_64 = "yes"; then elif test -f $SYBASE_CT_LIBDIR/libsybct.so; then I also merged that to 5_3 and 5_4 Guess this really is about the â%dâ vs. â%ldâ warning here. 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=55009 -- Edit this bug report at http://bugs.php.net/bug.php?id=55009&edit=1
Req #55051 [Opn->Bgs]: bag with function str_replace
Edit report at http://bugs.php.net/bug.php?id=55051&edit=1
ID: 55051
Updated by: ras...@php.net
Reported by:kloas at mail dot ru
Summary:bag with function str_replace
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:PHP options/info functions
Operating System: win 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
As the docs state, if the search and replace params are arrays, their elements
are processed first to last. That means it iterates over the string and does
each replacement from the arrays one by one, left to right. That means you have
these steps:
1234567890 Original string
9234567890 Replace all 1's with 9's
9834567890 Replace all 2's with 8's
9874567890 Replace all 3's with 7's
9876567890 Replace all 4's with 6's
9876567890 Replace all 5's with 5's
9874547890 Replace all 6's with 4's
9834543890 Replace all 7's with 3's
9234543290 Replace all 8's with 2's
1234543210 Replace all 9's with 1's
If you want to translate chars in a single pass, use strtr()
eg. echo strtr("1234567890","9876543210",$str);
Previous Comments:
[2011-06-14 00:20:49] kloas at mail dot ru
Description:
hi? im from russian? english is bad
so here code with bug
echo 1234543210
Test script:
---
must be 0987654321
Expected result:
Actual result:
--
--
Edit this bug report at http://bugs.php.net/bug.php?id=55051&edit=1
Bug #55044 [Bgs]: web site bug, en lang code, shows Brazilian Portugese
Edit report at http://bugs.php.net/bug.php?id=55044&edit=1 ID: 55044 User updated by:jmichae3 at yahoo dot com Reported by:jmichae3 at yahoo dot com Summary:web site bug, en lang code, shows Brazilian Portugese Status: Bogus Type: Bug Package:Other web server Operating System: windows xp Pro sp3 32-bit PHP Version:5.3.6 Block user comment: N Private report: N New Comment: that is not how most web sites work. most web sites work by having a VERY SIMPLE dropdown listbox that shows you what language is selected and allows you to select a different language. at least knowing what language you are in would be helpful for people who work with multiple languages if you are not going to change the methodology. the way things are now is causing confusion with more than one person. Previous Comments: [2011-06-13 16:08:36] dtajchre...@php.net That drop down is to the view the page in another language... note the little text next to it "view this page in". If you change it to Brazilian Portugese and then click the drop down again, you'll notice you can view the page in English. [2011-06-13 12:12:18] jmichae3 at yahoo dot com Description: the php web site has a problem. http://us.php.net/manual/en/features.file-upload.multiple.php all over PHP site it says it is in Brazilian Portugese, yet the language code is en (English). My machine is US English. go figure. in the documentation selection boxes it does not list English as a language, but it lists Brazilian Portugese. I will bet that most people don't know what Brazilian Portugese is. but they know what English is. and that's what this language is in despite the title. please fix. Test script: --- install US English version of windows. http://us.php.net/manual/en/features.file-upload.multiple.php look at language dropdown box Expected result: the word English for en language code on web site anywhere language is mentioned Actual result: -- I find the words Brazilian Portugese all over web site anywhere language is mentioned. -- Edit this bug report at http://bugs.php.net/bug.php?id=55044&edit=1
[PHP-BUG] Req #55051 [NEW]: bag with function str_replace
From: Operating system: win 7 PHP version: 5.3.6 Package: PHP options/info functions Bug Type: Feature/Change Request Bug description:bag with function str_replace Description: hi? im from russian? english is bad so here code with bug echo 1234543210 Test script: --- must be 0987654321 Expected result: Actual result: -- -- Edit bug report at http://bugs.php.net/bug.php?id=55051&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55051&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55051&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55051&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55051&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55051&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55051&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55051&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55051&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55051&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55051&r=support Expected behavior: http://bugs.php.net/fix.php?id=55051&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55051&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55051&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55051&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55051&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55051&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55051&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55051&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55051&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55051&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55051&r=mysqlcfg
Bug #55048 [Opn->Csd]: Garbage is Never Collected
Edit report at http://bugs.php.net/bug.php?id=55048&edit=1
ID: 55048
User updated by:kvonlaven at yahoo dot com
Reported by:kvonlaven at yahoo dot com
Summary:Garbage is Never Collected
-Status: Open
+Status: Closed
Type: Bug
Package:Session related
Operating System: CentOS 5.3
-PHP Version:Irrelevant
+PHP Version:5.2.6-1+lenny10
Block user comment: N
Private report: N
New Comment:
I just got it to work. It turns out the settings in php.ini were being
completely ignored and
overwritten with the following values:
session.gc_probability = 0
session.gc_divisor = 100
session.gc_maxlifetime = 1440
Understandbly this meant the garbage was never being collected. This is a
little surprising
because I thought the default value of session.gc_probability was supposed to
be 1. In any case,
the reason my php.ini settings were being ignored is that I didn't put quotes
around the string I
assigned to a different ini variable.
Previous Comments:
[2011-06-13 21:26:37] kvonlaven at yahoo dot com
Description:
I'm using PHP version 5.2.6-1+lenny10. I would upgrade or try using an SVN
snapshot if I could, but I don't have administrator privileges on the server
I'm
using :-/.
Below is an excerpt from my php.ini file.
session.gc_probability = 1
session.gc_divisor = 1
session.gc_maxlifetime = 3600
I also have a call to session_save_path('Session Data') and
ini_set('session.gc_maxlifetime', 3600) right before session_start() gets
called.
These three functions get called at the top of every page before any output is
sent from the server.
Test script:
---
I executed the following script to verify that PHP has the appropriate
privileges to delete temporary session files, and it deleted the file as
expected.
Expected result:
My understanding is that, using this configuration, the garbage collector
should
completely delete all temporary session files in the "Session Data" directory
that
are over an hour old every time anybody goes to any page on the site.
Actual result:
--
I have empty temporary session files in the "Session Data" folder that are
several
days old but have yet to be deleted.
--
Edit this bug report at http://bugs.php.net/bug.php?id=55048&edit=1
Bug #53722 [Com]: FILTER_VALIDATE_EMAIL fails on numeric TLDs
Edit report at http://bugs.php.net/bug.php?id=53722&edit=1 ID: 53722 Comment by: deadalnix at gmail dot com Reported by:romain dot riviere at gmail dot com Summary:FILTER_VALIDATE_EMAIL fails on numeric TLDs Status: Bogus Type: Bug Package:Filter related Operating System: Linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Hi, I want to enlight the PHP team about https://www.42registry.org/ . This TLD is more and more recognized and used, and we will reach a point where not supporting numerical TLD will be a major problem. Previous Comments: [2011-03-21 03:02:54] barkerjr at barkerjr dot net This bug should be reopened. We don't want PHP to be broken in the event that a numeric TLD is created. [2011-02-18 16:24:09] romain dot riviere at gmail dot com Precisely. FILTER_VALIDATE_EMAIL should validate *technically* correct email addresses, not just ICANN-correct ones. It is already the case for .foo or .bar TLDs, it just needs to do the same for numeric TLDs, because from a technical point of view, there are no different: old restrictions in old RFCs have all been superseded now. [2011-02-13 23:30:16] frank9321 at gmail dot com I think that Romain in right. There are numeric TLDs (like the .42 TLD wich is taking off), and sometimes, as Romain said, you use such TLDs in your LAN. So, really, the FILTER_VALIDATE_EMAIL should accept numeric TLDs. It isn't because the ICANN said that there couldn't be numeric TLDs that there aren't. [2011-01-18 14:15:16] romain dot riviere at gmail dot com There ARE numeric TLDs, even though they are not made public. I have one on my LAN. The filter should probably not rely on what is believed to exist, but on what is technically feasible. In other words, if I can get email on the address johndoe@domain.123 (and again, YES, it works), then FILTER_VALIDATE_EMAIL should not reject such an address. [2011-01-18 14:03:15] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php There are no numeric TLDs, the e-mail filters supports IP based e-mail addresses however. 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=53722 -- Edit this bug report at http://bugs.php.net/bug.php?id=53722&edit=1
[PHP-BUG] Bug #55048 [NEW]: Garbage is Never Collected
From:
Operating system: CentOS 5.3
PHP version: Irrelevant
Package: Session related
Bug Type: Bug
Bug description:Garbage is Never Collected
Description:
I'm using PHP version 5.2.6-1+lenny10. I would upgrade or try using an SVN
snapshot if I could, but I don't have administrator privileges on the
server I'm
using :-/.
Below is an excerpt from my php.ini file.
session.gc_probability = 1
session.gc_divisor = 1
session.gc_maxlifetime = 3600
I also have a call to session_save_path('Session Data') and
ini_set('session.gc_maxlifetime', 3600) right before session_start() gets
called.
These three functions get called at the top of every page before any output
is
sent from the server.
Test script:
---
I executed the following script to verify that PHP has the appropriate
privileges to delete temporary session files, and it deleted the file as
expected.
Expected result:
My understanding is that, using this configuration, the garbage collector
should
completely delete all temporary session files in the "Session Data"
directory that
are over an hour old every time anybody goes to any page on the site.
Actual result:
--
I have empty temporary session files in the "Session Data" folder that are
several
days old but have yet to be deleted.
--
Edit bug report at http://bugs.php.net/bug.php?id=55048&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=55048&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=55048&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=55048&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=55048&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=55048&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=55048&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=55048&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=55048&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=55048&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=55048&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=55048&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=55048&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=55048&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=55048&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55048&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=55048&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=55048&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=55048&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=55048&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=55048&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=55048&r=mysqlcfg
Bug #55047 [Opn]: \ResourceBundle misses keys
Edit report at http://bugs.php.net/bug.php?id=55047&edit=1
ID: 55047
User updated by:franssen dot roland at gmail dot com
Reported by:franssen dot roland at gmail dot com
Summary:\ResourceBundle misses keys
Status: Open
Type: Bug
Package:I18N and L10N related
Operating System: Ubuntu 11.04
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Until ICU4C library 4.2 all keys seem to be available
Previous Comments:
[2011-06-13 19:32:53] franssen dot roland at gmail dot com
Description:
I currently use the \ResourceBundle class from the intl extension. After an
upgrade to 5.3.6 some essental keys were missing.
Before i used a ICU4C data library for 3.8.1, after the upgrade i noticed ICU
version upgraded too (4.4.1). Using \ResourceBundle with the new data library
results in unknown keys, downgrading the data library resolves it.
Created the data library at;
http://apps.icu-project.org/datacustom/ICUData38.html
http://apps.icu-project.org/datacustom/ICUData44.html
See also;
http://site.icu-project.org/design/resbund/issues
Test script:
---
get('Languages'));
var_dump($res->getErrorMessage());
$res = new \ResourceBundle('en_US', '/usr/data/icu441', true);
var_dump($res->get('Languages'));
var_dump($res->getErrorMessage());
Expected result:
object(ResourceBundle)
"U_ZERO_ERROR"
object(ResourceBundle)
"U_ZERO_ERROR"
Actual result:
--
object(ResourceBundle)
"U_ZERO_ERROR"
NULL
"Cannot load resource element 'Languages': U_MISSING_RESOURCE_ERROR"
--
Edit this bug report at http://bugs.php.net/bug.php?id=55047&edit=1
[PHP-BUG] Bug #55047 [NEW]: \ResourceBundle misses keys
From:
Operating system: Ubuntu 11.04
PHP version: 5.3.6
Package: I18N and L10N related
Bug Type: Bug
Bug description:\ResourceBundle misses keys
Description:
I currently use the \ResourceBundle class from the intl extension. After an
upgrade to 5.3.6 some essental keys were missing.
Before i used a ICU4C data library for 3.8.1, after the upgrade i noticed
ICU version upgraded too (4.4.1). Using \ResourceBundle with the new data
library results in unknown keys, downgrading the data library resolves it.
Created the data library at;
http://apps.icu-project.org/datacustom/ICUData38.html
http://apps.icu-project.org/datacustom/ICUData44.html
See also;
http://site.icu-project.org/design/resbund/issues
Test script:
---
get('Languages'));
var_dump($res->getErrorMessage());
$res = new \ResourceBundle('en_US', '/usr/data/icu441', true);
var_dump($res->get('Languages'));
var_dump($res->getErrorMessage());
Expected result:
object(ResourceBundle)
"U_ZERO_ERROR"
object(ResourceBundle)
"U_ZERO_ERROR"
Actual result:
--
object(ResourceBundle)
"U_ZERO_ERROR"
NULL
"Cannot load resource element 'Languages': U_MISSING_RESOURCE_ERROR"
--
Edit bug report at http://bugs.php.net/bug.php?id=55047&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=55047&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=55047&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=55047&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=55047&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=55047&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=55047&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=55047&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=55047&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=55047&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=55047&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=55047&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=55047&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=55047&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=55047&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55047&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=55047&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=55047&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=55047&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=55047&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=55047&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=55047&r=mysqlcfg
Bug #55032 [Com]: Treating null, boolean and numbers as arrays does not trigger an error
Edit report at http://bugs.php.net/bug.php?id=55032&edit=1 ID: 55032 Comment by: cagret at gmail dot com Reported by:cagret at gmail dot com Summary:Treating null, boolean and numbers as arrays does not trigger an error Status: Open Type: Bug Package:Variables related Operating System: Linux, Windows PHP Version:5.3.6 Block user comment: N Private report: N New Comment: If implementing it is a performance problem (can't think of any other reason why it still hasn't been fixed), then you could at least give us an option, for example a php.ini option "check_types" that would be checking for such error. That would allow us to enable this option on Developer machines during testings and hopefully we would catch and fix all of these errors before uploading the code to the Production machine. Previous Comments: [2011-06-11 02:19:47] cagret at gmail dot com Description: This bug is really annoying and generates many headeaches to millions of php developers. It's really hard to detect this bug sometimes, and that is because we have so much faith in PHP and we think that it's not possible that php would allow us to write such a nonsensical code and not throw an error, after all didn't we set the most strict error reporting you allow us to set? This example code should be self explanatory: Please fix it ASAP. Thank you for your time. -- Edit this bug report at http://bugs.php.net/bug.php?id=55032&edit=1
Bug #55046 [Opn->Bgs]: strtotime ->wrong results with "first wednesday june 2011"
Edit report at http://bugs.php.net/bug.php?id=55046&edit=1
ID: 55046
Updated by: dtajchre...@php.net
Reported by:privat at thomasruecker dot at
Summary:strtotime ->wrong results with "first wednesday june
2011"
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Your string is relative to the current date. You need to add the word 'of' to
get
the first Wednesday of a given month.
[1] http://codepad.viper-7.com/qP9XIc
[2] http://www.php.net/manual/en/datetime.formats.relative.php
Previous Comments:
[2011-06-13 16:33:41] privat at thomasruecker dot at
This is always the case with the "number dayofweek month year" syntax, whenever
you choose the "dayofweek" that correlates with the 1st of the month.
for example
If the 1.MM. is a wednesday, then "first wednesday month " returns
08.MM., "second wednesday month " returns 15.MM. and so on.
[2011-06-13 16:30:15] privat at thomasruecker dot at
Description:
$timestr="first wednesday june 2011";
echo date("d.m.Y",strtotime($timestr));
Then the result is the 08.06.2011, and not the 01.06.2011 as i expected.
This happens whenever the "first" should be the 01.XX.
Same thing happens with the "second","third","fourth","fifth".
Test script:
---
$timestr="first wednesday june 2011";
echo date("d.m.Y",strtotime($timestr));
Expected result:
01.06.2011
Actual result:
--
08.06.2011
--
Edit this bug report at http://bugs.php.net/bug.php?id=55046&edit=1
Bug #55046 [Com]: strtotime ->wrong results with "first wednesday june 2011"
Edit report at http://bugs.php.net/bug.php?id=55046&edit=1
ID: 55046
Comment by: privat at thomasruecker dot at
Reported by:privat at thomasruecker dot at
Summary:strtotime ->wrong results with "first wednesday june
2011"
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
This is always the case with the "number dayofweek month year" syntax, whenever
you choose the "dayofweek" that correlates with the 1st of the month.
for example
If the 1.MM. is a wednesday, then "first wednesday month " returns
08.MM., "second wednesday month " returns 15.MM. and so on.
Previous Comments:
[2011-06-13 16:30:15] privat at thomasruecker dot at
Description:
$timestr="first wednesday june 2011";
echo date("d.m.Y",strtotime($timestr));
Then the result is the 08.06.2011, and not the 01.06.2011 as i expected.
This happens whenever the "first" should be the 01.XX.
Same thing happens with the "second","third","fourth","fifth".
Test script:
---
$timestr="first wednesday june 2011";
echo date("d.m.Y",strtotime($timestr));
Expected result:
01.06.2011
Actual result:
--
08.06.2011
--
Edit this bug report at http://bugs.php.net/bug.php?id=55046&edit=1
[PHP-BUG] Bug #55046 [NEW]: strtotime ->wrong results with "first wednesday june 2011"
From:
Operating system: Linux
PHP version: 5.2.17
Package: Date/time related
Bug Type: Bug
Bug description:strtotime ->wrong results with "first wednesday june 2011"
Description:
$timestr="first wednesday june 2011";
echo date("d.m.Y",strtotime($timestr));
Then the result is the 08.06.2011, and not the 01.06.2011 as i expected.
This happens whenever the "first" should be the 01.XX.
Same thing happens with the "second","third","fourth","fifth".
Test script:
---
$timestr="first wednesday june 2011";
echo date("d.m.Y",strtotime($timestr));
Expected result:
01.06.2011
Actual result:
--
08.06.2011
--
Edit bug report at http://bugs.php.net/bug.php?id=55046&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=55046&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=55046&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=55046&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=55046&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=55046&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=55046&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=55046&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=55046&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=55046&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=55046&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=55046&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=55046&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=55046&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=55046&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55046&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=55046&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=55046&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=55046&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=55046&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=55046&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=55046&r=mysqlcfg
Bug #55044 [Opn->Bgs]: web site bug, en lang code, shows Brazilian Portugese
Edit report at http://bugs.php.net/bug.php?id=55044&edit=1 ID: 55044 Updated by: dtajchre...@php.net Reported by:jmichae3 at yahoo dot com Summary:web site bug, en lang code, shows Brazilian Portugese -Status: Open +Status: Bogus Type: Bug Package:Other web server Operating System: windows xp Pro sp3 32-bit PHP Version:5.3.6 Block user comment: N Private report: N New Comment: That drop down is to the view the page in another language... note the little text next to it "view this page in". If you change it to Brazilian Portugese and then click the drop down again, you'll notice you can view the page in English. Previous Comments: [2011-06-13 12:12:18] jmichae3 at yahoo dot com Description: the php web site has a problem. http://us.php.net/manual/en/features.file-upload.multiple.php all over PHP site it says it is in Brazilian Portugese, yet the language code is en (English). My machine is US English. go figure. in the documentation selection boxes it does not list English as a language, but it lists Brazilian Portugese. I will bet that most people don't know what Brazilian Portugese is. but they know what English is. and that's what this language is in despite the title. please fix. Test script: --- install US English version of windows. http://us.php.net/manual/en/features.file-upload.multiple.php look at language dropdown box Expected result: the word English for en language code on web site anywhere language is mentioned Actual result: -- I find the words Brazilian Portugese all over web site anywhere language is mentioned. -- Edit this bug report at http://bugs.php.net/bug.php?id=55044&edit=1
[PHP-BUG] Req #55045 [NEW]: openssl_pkcs7_sign() & openssl_pkcs7_encrypt()
From: Operating system: arch linux x86_64 PHP version: 5.3.6 Package: OpenSSL related Bug Type: Feature/Change Request Bug description:openssl_pkcs7_sign() & openssl_pkcs7_encrypt() Description: --- >From manual page: http://www.php.net/function.openssl-pkcs7-sign#Description --- I would like to see the openssl_pkcs7_sign(), openssl_pkcs7_verify(), openssl_pkcs7_encrypt(), openssl_pkcs7_decrypt() functions use either a file for input & output or a string variable. When it comes to shared hosting environments writing files is not always available. Thanks. -- Edit bug report at http://bugs.php.net/bug.php?id=55045&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55045&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55045&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55045&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55045&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55045&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55045&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55045&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55045&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55045&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55045&r=support Expected behavior: http://bugs.php.net/fix.php?id=55045&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55045&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55045&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55045&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55045&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55045&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55045&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55045&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55045&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55045&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55045&r=mysqlcfg
Req #52657 [Com]: create a spl_object_id function
Edit report at http://bugs.php.net/bug.php?id=52657&edit=1
ID: 52657
Comment by: rasmus at mindplay dot dk
Reported by:marco dot weber at uni-trier dot de
Summary:create a spl_object_id function
Status: Open
Type: Feature/Change Request
Package:SPL related
Operating System: ANY
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I don't think attaching a serial number to every object from the get-go is a
good
approach, since this will add overhead (memory and CPU) for every object
constructed. Objects are relatively lightweight in PHP, and sacrificing that
for a
feature that is probably less commonly used, to me, is unacceptable.
What I would propose, is to assign a serial number the first time you access an
object - something along the lines of this:
public function object_serial($object)
{
static $next_sn = 1;
if (!isset($object->__sn__))
$object->__sn__ = $next_sn++;
return $object->__sn__;
}
You don't need to keep a serial-number in-memory until it's actually needed,
and
at that point, we'll just check and see if it already has an assigned serial-
number.
This is much simpler and easier on system-resources - the serial number is much
lighter than the 32-character hash, and will work just as well. And since
you're
most likely going to use this value as index in an array, hash indexes will
take
up less memory, and lookups will probably be cheaper too.
Unfortunately the PHP version of this collides with the magic __set() method,
which is why the function shown above won't always work.
If there were a way to go around the __get() and __set() methods, and directly
access the properties of an object without colliding with these magic methods,
that would probably be an even better solution. I would consider such a feature
as
belonging to the reflection domain - something like
ReflectionObject::getValue($object, $name) and
ReflectionObject::setValue($object,
$name, $value) would do the trick.
(this would probably have other uses too, so perhaps that's an even better
solution to this problem, seeing as how implementing your own object_serial()
method is literally only a few lines of code...)
Previous Comments:
[2011-06-13 10:44:11] marco dot weber at uni-trier dot de
i know, that there is nothing wrong with that method, as it does exactly, what
the documentation says. Nevertheless, it would be great to have another
function like spl_object_id(), that generates unique ids...
Quotation from [2010-08-20 15:34 UTC] marco dot weber at uni-trier dot de :
Since there is nothing wrong, with the spl_object_hash() method, i suggest to
introduce a new spl_object_id() function. This could simply return an
(internal) uint32, that is attached to every object on its creation. This
counter gets incremented on every object that gets created. :)
[2011-06-13 04:18:41] rasmus at mindplay dot dk
I agree, this is a vital feature.
Also, the description of spl_object_hash() in the documentation is highly
misleading:
"This function returns a unique identifier for the object. This id can be used
as a hash key for storing objects or for identifying an object."
It does NOT always return a unique identifier, not even within a single running
script. And it CANNOT be used as a key for storing objects, neither can it be
used to identify an object. In fact, in the footnote, it basically says so:
"When an object is destroyed, its hash may be reused for other objects."
That fact precludes the uses mentioned in the first part of the documentation.
I don't know what the intended use of that function is. It seems like it was an
attempt to provide the functionality described in the first part of the
documentation, because those are definitely things that could be put to good
use
in object-relational mappers, test-frameworks, etc...
[2010-08-21 07:59:04] giorgio dot liscio at email dot it
i've experienced problems with uniqueness ofspl_object_hash
i think should be rebuilt with a better one algorithm
there is no need (i think) of another function, just fix spl_object_hash
i think it is really important to fix
[2010-08-20 17:38:19] marco dot weber at uni-trier dot de
i've forgotten to write down the test1 class:
class test1 {
public function __construct($s) { }
}
[2010-08-20 17:34:25] marco dot weber at uni-trier dot de
Description:
the problem with spl_object_hash is, that it is only unqiue
Bug #54744 [Bgs]: ob_gzhandler does not work
Edit report at http://bugs.php.net/bug.php?id=54744&edit=1 ID: 54744 User updated by:bugzilla33 at gmail dot com Reported by:bugzilla33 at gmail dot com Summary:ob_gzhandler does not work Status: Bogus Type: Bug Package:Output Control Operating System: win32 PHP Version:trunk-SVN-2011-05-16 (snap) Block user comment: N Private report: N New Comment: Felipe, please write about replacement of ob_gzhandler in PHP 5.4+. Previous Comments: [2011-06-12 02:37:07] fel...@php.net ob_gzhandler() is not a PHP function anymore (5.4+). So the execution is being aborted by the fatal error. [2011-05-16 10:26:17] bugzilla33 at gmail dot com Description: ob_gzhandler does not work Test script: --- Expected result: prints 'ok' like PHP 5.3.6 Actual result: -- PHP 5.3.99 prints empty buffer -- Edit this bug report at http://bugs.php.net/bug.php?id=54744&edit=1
[PHP-BUG] Bug #55044 [NEW]: web site bug, en lang code, shows Brazilian Portugese
From: Operating system: windows xp Pro sp3 32-bit PHP version: 5.3.6 Package: Other web server Bug Type: Bug Bug description:web site bug, en lang code, shows Brazilian Portugese Description: the php web site has a problem. http://us.php.net/manual/en/features.file-upload.multiple.php all over PHP site it says it is in Brazilian Portugese, yet the language code is en (English). My machine is US English. go figure. in the documentation selection boxes it does not list English as a language, but it lists Brazilian Portugese. I will bet that most people don't know what Brazilian Portugese is. but they know what English is. and that's what this language is in despite the title. please fix. Test script: --- install US English version of windows. http://us.php.net/manual/en/features.file-upload.multiple.php look at language dropdown box Expected result: the word English for en language code on web site anywhere language is mentioned Actual result: -- I find the words Brazilian Portugese all over web site anywhere language is mentioned. -- Edit bug report at http://bugs.php.net/bug.php?id=55044&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55044&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55044&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55044&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55044&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55044&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55044&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55044&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55044&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55044&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55044&r=support Expected behavior: http://bugs.php.net/fix.php?id=55044&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55044&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55044&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55044&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55044&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55044&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55044&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55044&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55044&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55044&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55044&r=mysqlcfg
Bug #52480 [Com]: Incorrect difference using DateInterval
Edit report at http://bugs.php.net/bug.php?id=52480&edit=1
ID: 52480
Comment by: petros at rufunka dot com
Reported by:alex dot joyce at staff dot comcen dot com dot au
Summary:Incorrect difference using DateInterval
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Debian 5.0.3
PHP Version:5.3.3
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
The problem lies between the last day of February and first day of March.
At the following example:
$first = new DateTime('2011-03-01');
$second = new DateTime('2011-03-29');
$interval = $second->diff($first);
will get the wrong result.
If I set my timezone to Europe/Stockholm which is +1 GMT then if i set the
$first = new DateTime(â2011-03-01 00:59:00â²); I still get the wrong result.
However an hour value above or equal to +1 ie $first = new
DateTime(â2011-03-01 01:00:00â²); will give the correct example.
So if you are GMT + 2 you need to have a value above or equal to 2011-03-01
02:00:00.
A quick fix, as mentioned above, is to set your timezone to UTC:
date_default_timezone_set(âUTCâ);
and in this case you match the time with the needed in order to get correct
results.
Another example with the opposite results is to set your timezone to:
date_default_timezone_set(âAmerica/Mexico_Cityâ);
$first = new DateTime(â2011-02-28 22:01:00â²);
$second = new DateTime(â2011-03-29 03:00:00â²);
then the diff will think that you are in the same month.
Previous Comments:
[2011-04-12 16:37:51] fischer at wild-east dot de
This happens only when setting a DateTime without the time part or a time below
02:00:00. At least for the 'Europe/Berlin' timezone.
[2010-07-30 10:46:55] der...@php.net
This is going to be a fun one to fix :-/
[2010-07-30 01:40:02] alex dot joyce at staff dot comcen dot com dot au
Changing the timezone shows a difference.
Australia/Sydney (default): 5 months
UTC: 4 months 28 days
[2010-07-29 09:35:01] degeb...@php.net
With the timezone set to Europe/Copenhagen, I get the same results as
submitter. When set to UTC, I get the same results on Rasmus. This is on Ubuntu
10.04.
daniel@daniel-laptop:~$ php -v
PHP 5.3.4-dev (cli) (built: Jul 29 2010 09:30:24)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[2010-07-29 09:15:41] ras...@php.net
I don't see why I can't reproduce it then. Try adding a call to
date_default_timezone_set() to the top of your script and work in UTC to
eliminate local timezone issues.
date_default_timezone_set('UTC');
$date_start = new DateTime('2010-03-01');
$date_end = new DateTime('2010-07-29');
$interval = $date_start->diff($date_end);
print_r($interval);
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=52480
--
Edit this bug report at http://bugs.php.net/bug.php?id=52480&edit=1
Bug #55009 [Fbk->Csd]: Error when compile
Edit report at http://bugs.php.net/bug.php?id=55009&edit=1 ID: 55009 Updated by: the...@php.net Reported by:hexes at mail dot ru Summary:Error when compile -Status: Feedback +Status: Closed Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 Assigned To:thekid 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: [2011-06-13 10:45:58] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312117 Log: - MFH suppression of compiler warning noted in bug #55009 [2011-06-13 10:45:24] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312116 Log: - MFH suppression of compiler warning noted in bug #55009 [2011-06-13 10:43:23] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=312115 Log: - Fix compiler warning about long vs. int in printf() # See bug #55009 # Compare to _server_message_handler() a little below, where this # is done the same way [2011-06-13 10:32:19] the...@php.net The "$SYBASE_CT_INCDIR/libsybct.so" issue was fixed by SVN rev 311917 in bug Bug #53540. $ svn up ext/sybase_ct/config.m4 At revision 312114. $ grep libsybct ext/sybase_ct/config.m4 elif test -f $SYBASE_CT_LIBDIR/libsybct64.so && test $PHP_SYBASE_64 = "yes"; then elif test -f $SYBASE_CT_LIBDIR/libsybct.so; then I also merged that to 5_3 and 5_4 Guess this really is about the â%dâ vs. â%ldâ warning here. [2011-06-11 20:29:30] fel...@php.net But using INCDIR on: elif test -f $SYBASE_CT_INCDIR/libsybct.so; then seems wrong. 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=55009 -- Edit this bug report at http://bugs.php.net/bug.php?id=55009&edit=1
Req #52657 [Com]: create a spl_object_id function
Edit report at http://bugs.php.net/bug.php?id=52657&edit=1
ID: 52657
Comment by: marco dot weber at uni-trier dot de
Reported by:marco dot weber at uni-trier dot de
Summary:create a spl_object_id function
Status: Open
Type: Feature/Change Request
Package:SPL related
Operating System: ANY
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
i know, that there is nothing wrong with that method, as it does exactly, what
the documentation says. Nevertheless, it would be great to have another
function like spl_object_id(), that generates unique ids...
Quotation from [2010-08-20 15:34 UTC] marco dot weber at uni-trier dot de :
Since there is nothing wrong, with the spl_object_hash() method, i suggest to
introduce a new spl_object_id() function. This could simply return an
(internal) uint32, that is attached to every object on its creation. This
counter gets incremented on every object that gets created. :)
Previous Comments:
[2011-06-13 04:18:41] rasmus at mindplay dot dk
I agree, this is a vital feature.
Also, the description of spl_object_hash() in the documentation is highly
misleading:
"This function returns a unique identifier for the object. This id can be used
as a hash key for storing objects or for identifying an object."
It does NOT always return a unique identifier, not even within a single running
script. And it CANNOT be used as a key for storing objects, neither can it be
used to identify an object. In fact, in the footnote, it basically says so:
"When an object is destroyed, its hash may be reused for other objects."
That fact precludes the uses mentioned in the first part of the documentation.
I don't know what the intended use of that function is. It seems like it was an
attempt to provide the functionality described in the first part of the
documentation, because those are definitely things that could be put to good
use
in object-relational mappers, test-frameworks, etc...
[2010-08-21 07:59:04] giorgio dot liscio at email dot it
i've experienced problems with uniqueness ofspl_object_hash
i think should be rebuilt with a better one algorithm
there is no need (i think) of another function, just fix spl_object_hash
i think it is really important to fix
[2010-08-20 17:38:19] marco dot weber at uni-trier dot de
i've forgotten to write down the test1 class:
class test1 {
public function __construct($s) { }
}
[2010-08-20 17:34:25] marco dot weber at uni-trier dot de
Description:
the problem with spl_object_hash is, that it is only unqiue for the existing
objects.
For a given Object:
class container {
protected $storage=array();
public function add(test1 $obj) {
if(!isset($this->storage[spl_object_hash($obj)])) {
$this->storage[spl_object_hash($obj)]=$obj;
}
}
}
This leads to a problem, that the add method receives the same hash in to
following cases:
CASE1:
$o=new container();
$o->add(new test1("lalala"));
$o->add(new test1("lololo")); // same hash, that's NOT ok!
CASE2:
$t=new test("lalala");
$o=new container();
$o->add($t);
$o->add($t); // same hash, that's ok!
Since there is nothing wrong, with the spl_object_hash() method, i suggest to
introduce a new spl_object_id() function. This could simply return an
(internal) uint32, that is attached to every object on its creation. This
counter gets incremented on every object that gets created. :)
Test script:
---
// just with spl_object_hash :/
class container {
protected $storage=array();
public function add(test1 $obj) {
if(!isset($this->storage[spl_object_hash($obj)])) {
$this->storage[spl_object_hash($obj)]=$obj;
}
}
}
$o=new container();
$o->add(new test1("lalala")); // will be added
$o->add(new test1("lololo")); // not added - NOT as expected
$t=new test("lalala");
$o=new container();
$o->add($t); // will be added
$o->add($t); // not added - as expected
Expected result:
// with the new spl_object_id function :)
class container {
protected $storage=array();
public function add(test1 $obj) {
if(!isset($this->storage[spl_object_id($obj)])) {
$this->storage[spl_object_id($obj)]=$obj;
}
}
}
$o=new container();
$o->add(new test1("lalala")); // will be added
$o->add(new test1("lololo")); // will be added
$t=new test("lalala");
$o=new container();
$o->add($t); // will be added
$o->add($t); // not added
--
Edit this bug report at ht
Bug #55009 [Fbk]: Error when compile
Edit report at http://bugs.php.net/bug.php?id=55009&edit=1 ID: 55009 Updated by: the...@php.net Reported by:hexes at mail dot ru Summary:Error when compile Status: Feedback Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 Assigned To:thekid Block user comment: N Private report: N New Comment: The "$SYBASE_CT_INCDIR/libsybct.so" issue was fixed by SVN rev 311917 in bug Bug #53540. $ svn up ext/sybase_ct/config.m4 At revision 312114. $ grep libsybct ext/sybase_ct/config.m4 elif test -f $SYBASE_CT_LIBDIR/libsybct64.so && test $PHP_SYBASE_64 = "yes"; then elif test -f $SYBASE_CT_LIBDIR/libsybct.so; then I also merged that to 5_3 and 5_4 Guess this really is about the â%dâ vs. â%ldâ warning here. Previous Comments: [2011-06-11 20:29:30] fel...@php.net But using INCDIR on: elif test -f $SYBASE_CT_INCDIR/libsybct.so; then seems wrong. [2011-06-11 20:25:27] the...@php.net This is the error as far as I see: /opt/sybase/OCS-15_0/include/ctpublic.h:269: error: expected declaration specifiers or â...â before âSQLDAâ It doesn't look like this has anything to do with PHP. [2011-06-09 10:11:19] hexes at mail dot ru /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:391: warning: format â%dâ expects type âintâ, but argument 5 has type âlong intâ just change %d to %ld. [2011-06-08 08:33:34] hexes at mail dot ru Description: In file included from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.h:63, from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:30: /opt/sybase/OCS-15_0/include/ctpublic.h:269: error: expected declaration specifiers or â...â before âSQLDAâ /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c: In function â_client_message_handlerâ: /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:391: warning: format â%dâ expects type âintâ, but argument 5 has type âlong intâ make: *** [ext/sybase_ct/php_sybase_ct.lo] Error 1 make: *** Waiting for unfinished jobs emake failed I think that error can be in config.m4 (str 60): elif test -f $SYBASE_CT_INCDIR/libsybct.so; then $PHP_SYBASE_CT = '/opt/sybase/OCS-15_0' $SYBASE_CT_INCDIR = $PHP_SYBASE_CT/include But libraries are located in: $SYBASE_CT_LIBDIR=$PHP_SYBASE_CT/lib ls /opt/sybase/OCS-15_0/include/ bkpublic.h cobpub.cbl csconfig.h cspublic.h cstypes.h ctpublic.h mcconfig.h mcpublic.h mctypes.h oscompat.h oserror.h ospublic.h sqlca.h sqlda.h srverror.h srv.h sybdb.h sybdbn.h syberror.h sybesql.c sybfront.h sybhesql.cbl sybhesql.h sybhstmt.h syblogin.h sybtesql.cbl sybtesql.h ls -1 /opt/sybase/OCS-15_0/lib/ libs.a libsmapp.a libsybblk.a libsybblk_r.a libsybblk_r.so libsybblk.so libsybcobct.a libsybcobct_r.a libsybcomn.a libsybcomn_r.a libsybcomn_r.so libsybcomn.so libsybcs.a libsybcs_r.a libsybcs_r.so libsybcs.so libsybct.a libsybct_r.a libsybct_r.so libsybct.so libsybdb.a libsybdb.so libsybdldap.so.15.0.0 libsybdldap.so.15.0.3 libsybfssl.so.15.0.0 libsybfssl.so.15.0.3 libsybintl.a libsybintl_r.a libsybintl_r.so libsybintl.so libsybskrb.so.15.0.0 libsybskrb.so.15.0.3 libsybtcl.a libsybtcl_r.a libsybtcl_r.so libsybtcl.so libsybunic.a libsybunic.so And also, there is no libs: PHP_ADD_LIBRARY(cs,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) -- Edit this bug report at http://bugs.php.net/bug.php?id=55009&edit=1
