Bug #65367 [Csd]: Segmentation fault when mixing = and =
Edit report at https://bugs.php.net/bug.php?id=65367edit=1
ID: 65367
Updated by: mbecc...@php.net
Reported by:mbecc...@php.net
Summary:Segmentation fault when mixing = and =
Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: Any
PHP Version:5.5.1
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Yes, this didn't make it into PHP 5.4.19 as it was branched off of 5.4.18.
Hopefully 5.4.20 will contain the fix (like 5.5.2 does).
Previous Comments:
[2013-09-18 17:28:31] jbozza at mindsites dot com
This bug has been listed as closed and fixed in git, but the problem still
remains in 5.4.19. Looking at the diff for both files fixed, the 5.4.19 source
code is still missing the changed lines.
According to the changelogs, 5.5.2 received the fixes on August 15, 2013, but
5.4.18 (released the same day) did not receive the fixes.
Can this be applied to 5.4.x? Comment at 2013-08-05 14:50 UTC, by
mbecc...@php.net even mentions 5.4.
[2013-08-06 07:45:27] larue...@php.net
thanks for the ssh access, it is helpful.
fixed in: http://git.php.net/?p=php-
src.git;a=commit;h=a831499b4a1029118dc45375e62af42043110ade
[2013-08-06 05:53:18] mbecc...@php.net
Yes, I've used a fresh git clone.
[2013-08-06 03:02:53] larue...@php.net
did you built it frome a fresh work dir?
[2013-08-05 14:50:51] mbecc...@php.net
I have upgraded PHP 5.4 to latest-git on a new machine. With the patch applied
I now see many test runs consistently fail with a segafult. Reverting to 5.4.17
fixes the segfault.
Backtrace is:
#0 0x009beb33 in zend_std_object_get_class (object=0x7fffef535cd0) at
/root/compile/php-src/Zend/zend_object_handlers.c:1500
zobj = 0x7fff0021
#1 0x0098dd98 in zend_get_class_entry (zobject=0x7fffef535cd0) at
/root/compile/php-src/Zend/zend_API.c:238
No locals.
#2 0x00a17121 in ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER
(execute_data=0x77fa1ea0)
at /root/compile/php-src/Zend/zend_vm_execute.h:29282
opline = 0x70a34228
function_name = 0x70a35058
function_name_strval = 0x77f97d50 setFileNameProtection
function_name_strlen = 21
#3 0x009c6513 in execute (op_array=0x1446f00) at
/root/compile/php-src/Zend/zend_vm_execute.h:410
ret = 0
execute_data = 0x77fa1ea0
nested = 1 '\001'
original_in_execution = 0 '\000'
#4 0x0098ca9f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/compile/php-src/Zend/zend.c:1315
files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fffae40, reg_save_area = 0x7fffad80}}
i = 1
file_handle = 0x7fffd1e0
orig_op_array = 0x0
orig_retval_ptr_ptr = 0x0
orig_interactive = 0
#5 0x00902ff4 in php_execute_script (primary_file=0x7fffd1e0) at
/root/compile/php-src/main/main.c:2497
realfile =
/home/atlassian/bamboo/xml-data/build-dir/AP-RET-P53P/tests/run.php\000\000\000\000\000\021,
'\000' repeats 15 times,
P\301\377\377\377\177\000\000\336U\225\000\000\000\000\000\234\066\336\367\377\177\000\000\000\020$\001\000\000\000\000\016\000\000\000\000\000\000\000\260\302\377\377\377\177\000\000-\000\000\000\000\000\000\000fII\\000\000\000\000\240\336\367\377\177\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000%%\211\000\000\000\000\000\030\255\231\365\377\177\000\000\214\236\231\365\377\177\000\000...
__orig_bailout = 0x7fffd2f0
__bailout = {{__jmpbuf = {0, -26362260470167, 4380576,
140737488348720, 0, 0, -263622602725482883, 263621642691976829},
__mask_was_saved = 0, __saved_mask = {__val = {0, 0,
140737314399616, 140737488343184, 0, 140737488343200, 4380576, 140737488348720,
0, 0,
9431409, 140737488344000, 140737488349319, 19186208,
287762808856, 21253568
prepend_file_p = 0x0
append_file_p = 0x0
prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0,
opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0,
isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0,
old_handle = 0x0, old_closer = 0x0}, reader = 0x0, fsizer = 0x0,
closer = 0x0}}, free_filename = 0 '\000'}
append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path
= 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0,
mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0,
[PHP-BUG] Bug #65704 [NEW]: curl_multi does not work with libcurl = 7.32
From: gil at disatnik dot com Operating system: Linux PHP version: 5.5.3 Package: cURL related Bug Type: Bug Bug description:curl_multi does not work with libcurl = 7.32 Description: Hello. I have noticed that curl_multi does not work with some of my machines running php 5.5.3. I have confirmed the same behavior in both Debian unstable and Ubuntu (installed 13.10 beta that comes with 5.5.3 so I could see if it has the same problem) I noticed that when I installed php 5.5.3 on Ubuntu 12.04 (using libcurl 7.22 - (4.2.0.so)) everything works as expected so my guess would be that this is some sort of incompatibility with the newer curl version (both Ubuntu 13.10 and Debian unstable are running curl 7.32 (4.3.0.so)) My own POC script simply creates empty files and the sample from php.net doesn't work (hangs and does nothing). Test script: --- Example from php.net: http://php.net/manual/en/function.curl-multi-exec.php My own test script : http://pastebin.com/jytDnqBp -- Edit bug report at https://bugs.php.net/bug.php?id=65704edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65704r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65704r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65704r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65704r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65704r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65704r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65704r=needscript Try newer version: https://bugs.php.net/fix.php?id=65704r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65704r=support Expected behavior: https://bugs.php.net/fix.php?id=65704r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65704r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65704r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65704r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65704r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65704r=dst IIS Stability: https://bugs.php.net/fix.php?id=65704r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65704r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65704r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65704r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65704r=mysqlcfg
[PHP-BUG] Bug #65705 [NEW]: simplexml_load_string does not honor error_reporting settting
From: oskar dot mothander at gmail dot com
Operating system: Windows 7 (64)
PHP version: 5.4.19
Package: SimpleXML related
Bug Type: Bug
Bug description:simplexml_load_string does not honor error_reporting settting
Description:
Calling simplexml_load_string() on invalid xml will output Warnings even
though
you've been a good developer and turned these OFF on live environment.
Using libxml_use_internal_errors(true); fixes the problem but shouldn't
be
nessesary.
This caused my site to display Warnings live.
Affected versions:
PHP 5.4.3 (not in the list above?)
PHP 5.3.8 (VC9 X86 32bit thread safe) + PEAR
Test script:
---
ini_set(display_errors, false);
simplexml_load_string('apa');
// Will still output Warnings even though they are off.
Expected result:
Empty result
Actual result:
--
Warning: simplexml_load_string() [function.simplexml-load-string]: Entity:
line 1:
parser error : Premature end of data in tag apa line 1 on line 2
Warning: simplexml_load_string() [function.simplexml-load-string]: apa on
line 2
Warning: simplexml_load_string() [function.simplexml-load-string]: ^ on
line 2
--
Edit bug report at https://bugs.php.net/bug.php?id=65705edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65705r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65705r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65705r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65705r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65705r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65705r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65705r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65705r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65705r=support
Expected behavior: https://bugs.php.net/fix.php?id=65705r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65705r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65705r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65705r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65705r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65705r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65705r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65705r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65705r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65705r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65705r=mysqlcfg
Req-Bug #63911 [Opn-Ver]: Ignore conflicting trait methods originationg from identical sub traits
Edit report at https://bugs.php.net/bug.php?id=63911edit=1
ID: 63911
Updated by: g...@php.net
Reported by:bitluni at bitluni dot net
Summary:Ignore conflicting trait methods originationg from
identical sub traits
-Status: Open
+Status: Verified
-Type: Feature/Change Request
+Type: Bug
Package:Class/Object related
Operating System: debian
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
This is indeed a bug. Unfortunately, this case slipped and did not get tested.
It
is a perfectly valid usecase, and should not require the use of insteadof at
all.
Best regards
Stefan
Previous Comments:
[2013-09-15 17:23:42] heruan at aldu dot net
insteadOf in this case is just a workaround, since there is nothing to 'use
instead of' something else because here there is a property/method conflicting
with its very self!
And BTW insteadOf cannot be used as a workaround with properties.
[2013-05-03 10:26:44] simon at simon dot geek dot nz
This is still occurring with PHP 5.5, commit
cbe2870b72c4cfdb5c295e83c88d7cff5c39e396 (Fri May 3 12:25:49 2013 +0400).
Not being able to use multiple traits that have the same trait somewhere in
their
composition trees is a rather major limitation of the trait system.
[2013-01-06 10:31:40] bitluni at bitluni dot net
@necktrox
I know there is 'insteadof' but see my example, there is just one function
implemented yet still I get collision error. The traits are just usable very
flat at the moment. If you have an hirachical stucture of traits like I do, you
have to do potentally exponetial count of 'insteadof's in the top level class
even there's not one dublicate function implemented.
[2013-01-06 02:36:02] necktrox at gmail dot com
# from http://php.net/manual/de/language.oop5.traits.php
trait A {
public function smallTalk() {
echo 'a';
}
public function bigTalk() {
echo 'A';
}
}
trait B {
public function smallTalk() {
echo 'b';
}
public function bigTalk() {
echo 'B';
}
}
class Talker {
use A, B {
B::smallTalk insteadof A;
A::bigTalk insteadof B;
}
}
[2013-01-05 18:39:11] bitluni at bitluni dot net
same issue for properties
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63911
--
Edit this bug report at https://bugs.php.net/bug.php?id=63911edit=1
[PHP-BUG] Bug #65708 [NEW]: dba functions cast $key param to string in-place, bypassing copy on write
From: gary_whittles at hotmail dot com
Operating system: Fedora 17
PHP version: 5.5Git-2013-09-19 (Git)
Package: DBM/DBA related
Bug Type: Bug
Bug description:dba functions cast $key param to string in-place, bypassing
copy on write
Description:
Calling dba functions (e.g. dba_exists/dba_insert) with a non-string key
causes
the key to be cast to a string. This also affects any variables that are
copies
of the key variable.
This seems to be independent of database type - tested with db4 and
flatfile
databases.
Test script:
---
?php
$db = dba_open('/tmp/testdb', 'c', 'flatfile');
$i = 1; //use integer key
$j = $i; //copy by value
echo gettype($i).\n;
echo gettype($j).\n;
dba_exists($i, $db);
echo gettype($i).\n;
echo gettype($j).\n;
Expected result:
integer
integer
integer
integer
Actual result:
--
integer
integer
string
string
--
Edit bug report at https://bugs.php.net/bug.php?id=65708edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65708r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65708r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65708r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65708r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65708r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65708r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65708r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65708r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65708r=support
Expected behavior: https://bugs.php.net/fix.php?id=65708r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65708r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65708r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65708r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65708r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65708r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65708r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65708r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65708r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65708r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65708r=mysqlcfg
Bug #65636 [Com]: Stream path cannot contail null char (chr(0))
Edit report at https://bugs.php.net/bug.php?id=65636edit=1 ID: 65636 Comment by: bixuehujin at gmail dot com Reported by:bilge at scriptfusion dot com Summary:Stream path cannot contail null char (chr(0)) Status: Open Type: Bug Package:Streams related Operating System: Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: AFAIK, it is not possible to contain null character in a filename path, this is not because of PHP but the OS. At the OS level, it seems no way to handle a file contains null characters. Previous Comments: [2013-09-08 23:02:36] bilge at scriptfusion dot com Description: Stream path can contain any character, whether URL encoded or not, except for the null character. Including a null character in the path raises the following error: file_get_contents() expects parameter 1 to be a valid path, string given Both the use case and test suite to support the claims above can be found at https://github.com/Bilge/VerbatimStream/tree/eb185806f9bea3ee65b7d0f3e42dcd27a7b40614 The use case is a custom stream wrapper that takes the path and converts it into a read-only data stream. The current workaround is to urlencode any path that contains nulls. However, this approach provides little benefit over the data wrapper. Being able to include nulls directly in the path would eliminate unnecessary url encoding and decoding in the custom wrapper implementation. Test script: --- file_get_contents(\000); //or file_get_contents(verbatim://\000); Expected result: No error. Actual result: -- file_get_contents() expects parameter 1 to be a valid path, string given -- Edit this bug report at https://bugs.php.net/bug.php?id=65636edit=1
[PHP-BUG] Bug #65710 [NEW]: odbc_result or odbc_fetch_array cause php error memory
From: christophe dot conduche at bio-c-bon dot fr
Operating system: Fedora 19 ppc64p7
PHP version: 5.5.3
Package: ODBC related
Bug Type: Bug
Bug description:odbc_result or odbc_fetch_array cause php error memory
Description:
ODBC connexion to a DB2 database makes php out of memory on fedora 19
ppc64p7 arch.
Same script on a debian 64 bit box works ok.
SQLi gives correct results on the 2 test systems.
Test script:
---
?php
echo TEST CONNEXION DB2 - ODBC HR;
$dsn= power7;
$user = xxx;
$passwd = yyy;
$conn = odbc_connect($dsn,$user,$passwd );
if (!$conn)
{exit(Connection Failed: . $conn);}
$sql=SELECT 1 FROM SYSIBM.SYSDUMMY1;
$rs=odbc_exec($conn,$sql);
if (!$rs)
{exit(Error in SQL);}
$myarray = odbc_fetch_array($rs);
odbc_close($conn);
var_dump ($myarray);
echo HRFin de test;
?
Expected result:
TEST CONNEXION DB2 - ODBC
array(1) { [1]= string(1) 1 }
Fin de test
Actual result:
--
TEST CONNEXION DB2 - ODBC
array(1) { [1]= string(365)
1 ���jx ���jxlz��a ���j� ���j�lz` }
Fin de test
--
Edit bug report at https://bugs.php.net/bug.php?id=65710edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65710r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65710r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65710r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65710r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65710r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65710r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65710r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65710r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65710r=support
Expected behavior: https://bugs.php.net/fix.php?id=65710r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65710r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65710r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65710r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65710r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65710r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65710r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65710r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65710r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65710r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65710r=mysqlcfg
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1 ID: 64010 Comment by: andrebruce at gmail dot com Reported by:spam2 at rhsoft dot net Summary:htmlentities fundamentally broken in 5.4 Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.10 Block user comment: N Private report: N New Comment: Hello, I found this bug report searching for htmlentities broken I am seeing some broken applications like phppgadmin shipped with Ubuntu because of this change. Making it possible to change it globally on php.ini (or using the default_charset from php.ini) would be really interesting. Thanks. Previous Comments: [2013-09-02 18:05:25] spam2 at rhsoft dot net and again a broken backend on a production server running E_ALL reporting because the braindead idiot who made this change was not smart enugh to throw a *warning* if it returs an empty string while the input was not empty how stupid can developers act? [2013-01-17 18:41:04] spam2 at rhsoft dot net and last but not least WTF did whoever implemented the bullshit returning an emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that admins/developers which are running in E_ALL | E_STRICT since years smell if there something is still broken and need to get fixed? [2013-01-17 13:35:36] spam2 at rhsoft dot net and if you guys would be smart there would be an php.ini setting to specify the bahvior globally and/or per Directory instead hardcode incompatible changes breaking nearly ANY code written without wrappers [2013-01-17 13:33:21] spam2 at rhsoft dot net as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume that any input is UTF8 as default [2013-01-17 13:23:21] ras...@php.net If your page is ISO-8859-1 and you are using that as your internal encoding as well, then you need to specify that. Otherwise it leads to security issues. And since most people don't use ISO-8859-1 anymore, the safer default is to make sure we don't output invalid UTF-8 byte sequences when the developer has not specified the encoding. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64010 -- Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
[PHP-BUG] Bug #65714 [NEW]: PHP cli forces the tty to cooked mode
From: addw at phcomp dot co dot uk Operating system: Linux/Unix PHP version: 5.5.4 Package: CGI/CLI related Bug Type: Bug Bug description:PHP cli forces the tty to cooked mode Description: I am running a PHP script at the command line and piping the output through less: ./myScript | less Since less is an interactive program it puts the terminal into 'raw' mode so that it can read characters one at a time. However, when I do the above I find that the commands that I type to less are echoed back to me and not acted on until I type RETURN. This is not as it should be. The sript is not doing anything clever, just generating 100 lines: for($i = 0; $i 100; $i++) echo i=$i\n; This has been discussed on the Internals mail list, the thread starts here: http://marc.info/?l=php-internalsm=137915919531612w=2 Test script: --- I suggest a solution here: http://marc.info/?l=php-internalsm=137951748702534w=2 -- Edit bug report at https://bugs.php.net/bug.php?id=65714edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65714r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65714r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65714r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65714r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65714r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65714r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65714r=needscript Try newer version: https://bugs.php.net/fix.php?id=65714r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65714r=support Expected behavior: https://bugs.php.net/fix.php?id=65714r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65714r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65714r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65714r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65714r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65714r=dst IIS Stability: https://bugs.php.net/fix.php?id=65714r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65714r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65714r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65714r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65714r=mysqlcfg
Bug #65492 [Com]: Seeking beyond EOF leads to inconsistent results for key() and current()
Edit report at https://bugs.php.net/bug.php?id=65492edit=1 ID: 65492 Comment by: bixuehujin at gmail dot com Reported by:foo at example dot com Summary:Seeking beyond EOF leads to inconsistent results for key() and current() Status: Open Type: Bug Package:SPL related Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Sorry, the expect result should be: Expect result: string(4) foo string(4) bar Previous Comments: [2013-09-19 18:55:40] bixuehujin at gmail dot com Another inconsistent: Script: $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(0); var_dump($file-fgets()); $file-seek(1); var_dump($file-fgets()); Expect result: string(4) foo string(3) bar Actual result: -- string(4) foo string(3) baz BTW: --- The issue also existed in SplFileObject. [2013-08-21 06:56:34] foo at example dot com Sorry, the last line in the Test Script should read var_dump( $file-key(), $file-current() ); The problem does exist for fgetcsv() though, too. It will return NULL instead of the data at the last line. [2013-08-21 06:50:48] foo at example dot com Description: When seek()'ing beyond the end of file in an SplFileObject, SplFileObject::key() will return the number of the last line in the file but SplFileObject::current() will return false. This is inconsistent. Either SplFileObject::current() returns the content of the last line then, too. Or SplFileObject::key() should return false as well. As an alternative, SplFileObject::seek() could raise an OutOfBoundsException when trying to seek beyond EOF. Test script: --- $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(100); var_dump( $file-key(), $file-fgetcsv()); Expected result: int(2) baz or false false or OutOfBoundsException Actual result: -- int(2) NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=65492edit=1
Bug #65492 [Com]: Seeking beyond EOF leads to inconsistent results for key() and current()
Edit report at https://bugs.php.net/bug.php?id=65492edit=1 ID: 65492 Comment by: bixuehujin at gmail dot com Reported by:foo at example dot com Summary:Seeking beyond EOF leads to inconsistent results for key() and current() Status: Open Type: Bug Package:SPL related Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Another inconsistent: Script: $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(0); var_dump($file-fgets()); $file-seek(1); var_dump($file-fgets()); Expect result: string(4) foo string(3) bar Actual result: -- string(4) foo string(3) baz BTW: --- The issue also existed in SplFileObject. Previous Comments: [2013-08-21 06:56:34] foo at example dot com Sorry, the last line in the Test Script should read var_dump( $file-key(), $file-current() ); The problem does exist for fgetcsv() though, too. It will return NULL instead of the data at the last line. [2013-08-21 06:50:48] foo at example dot com Description: When seek()'ing beyond the end of file in an SplFileObject, SplFileObject::key() will return the number of the last line in the file but SplFileObject::current() will return false. This is inconsistent. Either SplFileObject::current() returns the content of the last line then, too. Or SplFileObject::key() should return false as well. As an alternative, SplFileObject::seek() could raise an OutOfBoundsException when trying to seek beyond EOF. Test script: --- $txt = TXT foo bar baz TXT; $file = new SplTempFileObject(-1); $file-fwrite($txt); $file-seek(100); var_dump( $file-key(), $file-fgetcsv()); Expected result: int(2) baz or false false or OutOfBoundsException Actual result: -- int(2) NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=65492edit=1
Bug #54254 [Com]: cal_from_jd returns month = 6 when there is only one Adar
Edit report at https://bugs.php.net/bug.php?id=54254edit=1 ID: 54254 Comment by: oc666 at netvision dot net dot il Reported by:asphp at dsgml dot com Summary:cal_from_jd returns month = 6 when there is only one Adar Status: Closed Type: Bug Package:Calendar related PHP Version:5.3.5 Assigned To:stas Block user comment: N Private report: N New Comment: I think the bug still exists. Under 5.4.9 I get the same results like in the reproduce example: Array ( [date] = 6/24/5772 [month] = 6 [day] = 24 [year] = 5772 [dow] = 0 [abbrevdayname] = Sun [dayname] = Sunday [abbrevmonth] = AdarI [monthname] = AdarI ) 0 29 Previous Comments: [2012-08-07 08:49:33] s...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. fixed in master [2012-03-29 18:33:50] asphp at dsgml dot com woordengeschrift you misunderstand the Hebrew calendar. In non-leap years there is a gap, the calendar months go: 4,5,7,8 - month 6 is skipped. Unfortunately PHP does 4,5,6,8 - it skips month 7 instead of 6 which is incorrect. In a leap year it is AdarI that is added - AdarII is the same as Adar. Yes, I know you would expect the second one to be the extra, but that's not how the calendar works. [2012-03-29 12:13:03] info at woordengeschrift dot nl In NON-leap years, there is only the unnumbered month of Adar. [2012-03-29 12:09:41] info at woordengeschrift dot nl In leap years, there is only the unnumbered month of Adar. Numbered Adars only occur in leap years: Adar_I (the actual leap month), followed by Adar_II. [2011-03-15 09:53:50] asphp at dsgml dot com Description: cal_from_jd() returns 6 for Adar when there is only one Adar, (it should return 7, since if there is only one Adar it's AdarII). It also says AdarI, which is wrong (it should be either Adar or at least AdarII). Furthermore the cal_days_in_month() (correctly) only works with month 7, and not 6 as returned by cal_from_jd. Test script: --- ? print_r(cal_from_jd(2456005, CAL_JEWISH)); echo cal_days_in_month(CAL_JEWISH, 6, 5772) . \n; echo cal_days_in_month(CAL_JEWISH, 7, 5772) . \n; ? Expected result: The month in cal_from_jd should be 7. The second two lines demonstrate how cal_days_in_month also expects the month to be 7. Actual result: -- Array ( [date] = 6/24/5772 [month] = 6 [day] = 24 [year] = 5772 [dow] = 0 [abbrevdayname] = Sun [dayname] = Sunday [abbrevmonth] = AdarI [monthname] = AdarI ) 0 29 -- Edit this bug report at https://bugs.php.net/bug.php?id=54254edit=1
[PHP-BUG] Req #65717 [NEW]: stat() should supply nano second granularity
From: addw at phcomp dot co dot uk Operating system: Any PHP version: Irrelevant Package: Filesystem function related Bug Type: Feature/Change Request Bug description:stat() should supply nano second granularity Description: Some systems (eg Linux on kernel 2.5.48) the 3 timestamp fields may be available with resolution of nanosecond. If these are available stat() should return in the array 3 extra members : atimensec, ctimensec and mtimensec. The resolution available also depends on the underlying file system. -- Edit bug report at https://bugs.php.net/bug.php?id=65717edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65717r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65717r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65717r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65717r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65717r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65717r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65717r=needscript Try newer version: https://bugs.php.net/fix.php?id=65717r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65717r=support Expected behavior: https://bugs.php.net/fix.php?id=65717r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65717r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65717r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65717r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65717r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65717r=dst IIS Stability: https://bugs.php.net/fix.php?id=65717r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65717r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65717r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65717r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65717r=mysqlcfg
Req #52657 [Com]: create a spl_object_id function
Edit report at https://bugs.php.net/bug.php?id=52657edit=1
ID: 52657
Comment by: metamarkers at gmail dot com
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:
Could be made into a magic property -__id
The id could just be a signed 64-bit counter that ticks up every time an object
is created. What would happen when you create more than
9,223,372,036,854,775,807
objects? Refactor, probably.
Previous Comments:
[2013-02-14 12:42:59] maciej dot sz at gmail dot com
An implementation of this is avaliable, and can be compiled as an extension:
http://stackoverflow.com/a/3089587/1697320
[2012-11-15 14:55:08] maciej dot sz at gmail dot com
@rasmus at mindplay dot dk: the thing is PHP already creates internal unique
index for each instantiated object. The requested spl_object_id() function
would only have to return it. You may have seen the value of this variable
while debugging your scripts. Have you not noticed the overhead? ;) Just
kidding.
Anyway, your idea for workaround seemed reasonable to me, and now thanks to the
traits in 5.4 I'm able to apply this unique object id to every class that I
need. Just use the below trait. It is also immune to the __get/__set issue. The
downside of this is that the id is a string containing class name. But if I'd
need an id that is unique only within a specific class scope I can use integer
value without the class name:
?php
/**
* Provides unique object's identifier.
*/
trait TObjectUniqueId
{
/**
* Object's unique id.
*
* @var int
*/
protected $__oid__ = null;
/**
* @return string
*/
public function getObjectUniqueId()
{
static $__object_index = 1;
if ( null === $this-__oid__ ) {
$this-__oid__ = __CLASS__ . '\\' . $__object_index++;
}
return $this-__oid__;
}
}
[2011-06-13 14:28:07] rasmus at mindplay dot dk
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...)
[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. :)
Req #47228 [Com]: New magic method like __call, but that is called even if the method exists
Edit report at https://bugs.php.net/bug.php?id=47228edit=1 ID: 47228 Comment by: metamarkers at gmail dot com Reported by:logy at logy dot com dot br Summary:New magic method like __call, but that is called even if the method exists Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Linux 2.6.20 PHP Version:5.2.8 Block user comment: N Private report: N New Comment: Well, that's a problem with Magento. Not PHP. Magento has objectively terrible design. Make your methods protected. __call() will be invoked if they're protected or private. If your system isn't flexible enough to allow that, and doesn't have some sort of event hook system, you need to reassess why you're using it in the first place. Previous Comments: [2013-01-26 08:19:00] info at ericdorr dot de Since 2009 and still no implementation. Where I have to apply as Developer to fix that ? [2012-06-12 21:48:43] sebastien dot roux dot dev at gmail dot com This problem can be solved in several ways when we can implements a design pattern on existing code, but when we works on products like magento when can't do anything, overiding classes ans methods is very strict and limited. The only way is to implement a new magic method like '__call' but called only if method exists. [2009-01-28 10:55:04] logy at logy dot com dot br Description: Not exactly a bug but i didn't find another good place to post it. I'd like to see a implemented magic method or something like that, with funcionality of the __call method but that hooks before any method that really EXISTS in the class. Something like that would be very util on implementations such as security and any other control over a multiple class design. I think PHP a wonderful language, but for the first time, I found a problem in the language that won't fit my design needs, so, I expect my solicitation to be valid. Reproduce code: --- - Expected result: - Actual result: -- - -- Edit this bug report at https://bugs.php.net/bug.php?id=47228edit=1
Req #47971 [Com]: Allow 'static' keyword to be applied to entire classes
Edit report at https://bugs.php.net/bug.php?id=47971edit=1
ID: 47971
Comment by: metamarkers at gmail dot com
Reported by:cscott at ggot dot org
Summary:Allow 'static' keyword to be applied to entire
classes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
Just a quick addendum, final abstract would disallow inheritance, which is
what
abstract classes are for. So static/final static would be cool.
Previous Comments:
[2013-09-19 22:17:52] metamarkers at gmail dot com
I think what you're describing is a final abstract class, which has been
suggested I think, though I can't find it in the requests.
So make an abstract class and use a trait to pull in an empty final private
constructor that triggers an E_USER_ERROR. But this is fighting with the
developer, and adds an unnecessary layer. The developer will always win. People
are free to throw a wrench into their own machinery if they want.
The flavor of the class should have no bearing on the default scope of its
members. Members need to be declared as the scope they should have. What you're
suggesting also implies we should be able to make protected and private classes
(in the global scope).
I'm in support of final abstract / static classes. Doesn't seem to be a
reason to disallow this. Some kind of declaration that says this class is
inert, you can't instantiate it.
[2012-12-18 05:57:03] phpmpan at mpan dot pl
One note:
PHP allows calling static methods on class instances and this actually works
faster* than pure static call. Compare:
for (... many times ...) {
UtilityClass::staticMethod();
}
vs
$instance = new UtilityClass();
for (... many times ...) {
$instance-staticMethod();
}
Creating an instance of a utility class is a neat optimization in heavy loops.
Do not consider me an advocate of premature optimization, but if g*to was
introduced in PHP because generated code may benefit from it, ability to create
instances of utility classes should not be prohibited for the same reason. If
OP's proposition is implemented, people will flock to it, effectively blocking
ability to use the described solution.
* 25% less time consumed; tests were performed about a year ago
[2012-10-26 16:09:57] dagguh at gmail dot com
What you are referring to is a utility class.
It only has static members and a private constructor, which should never be
called (even from the class itself).
Your suggestion could be useful, because implementing private empty
constructors
is just boilerplate code.
PS. Some people even throw an exception inside the private constructor.
[2009-10-31 00:27:53] cscott at ggot dot org
For Relevancy: I do not believe that namespaces solve this problem, as
__autoload does not work with namespaces (and, for obvious reasons,
shouldn't).
[2009-04-14 21:07:14] cscott at ggot dot org
Description:
Fairly simple: A developer is allowed to define his/her classes as abstract or
final, but not as static. For continuity's sake, it would be preferable to be
able to declare classes as static as well. This would greatly ease the
creation of static function collections/libraries, especially those included
with __autoload().
When a class is declared as abstract, it is a statement at the open that this
is an incomplete member; you can specify any method inside a class to be
abstract and the class is effectively abstract, yet this keyword is allowed in
the class declaration.
When a class is declared final, it is a statement at the open that all members
are to be considered final, and that this class should not be extended any
further.
By allowing classes to be declared as static, it would follow with allowing
abstract class foo in the sense that the keyword reflects the contents of the
class, and would follow with final class foo in that it would define a
binding construct for all members of the class.
Whether
a) In a static class, all methods and members are automatically static
-OR-
b) In a static class, all methods and members must be declared static
Is surely not for me to decide -- either is useful, as it either forces me to
ensure all members are static, or it does the legwork for me. As such, I make
no suggestion and defer to the wisdom of the developer(s).
Thank you for your consideration.
--
Edit this bug
Req #47971 [Com]: Allow 'static' keyword to be applied to entire classes
Edit report at https://bugs.php.net/bug.php?id=47971edit=1
ID: 47971
Comment by: metamarkers at gmail dot com
Reported by:cscott at ggot dot org
Summary:Allow 'static' keyword to be applied to entire
classes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
I think what you're describing is a final abstract class, which has been
suggested I think, though I can't find it in the requests.
So make an abstract class and use a trait to pull in an empty final private
constructor that triggers an E_USER_ERROR. But this is fighting with the
developer, and adds an unnecessary layer. The developer will always win. People
are free to throw a wrench into their own machinery if they want.
The flavor of the class should have no bearing on the default scope of its
members. Members need to be declared as the scope they should have. What you're
suggesting also implies we should be able to make protected and private classes
(in the global scope).
I'm in support of final abstract / static classes. Doesn't seem to be a
reason to disallow this. Some kind of declaration that says this class is
inert, you can't instantiate it.
Previous Comments:
[2012-12-18 05:57:03] phpmpan at mpan dot pl
One note:
PHP allows calling static methods on class instances and this actually works
faster* than pure static call. Compare:
for (... many times ...) {
UtilityClass::staticMethod();
}
vs
$instance = new UtilityClass();
for (... many times ...) {
$instance-staticMethod();
}
Creating an instance of a utility class is a neat optimization in heavy loops.
Do not consider me an advocate of premature optimization, but if g*to was
introduced in PHP because generated code may benefit from it, ability to create
instances of utility classes should not be prohibited for the same reason. If
OP's proposition is implemented, people will flock to it, effectively blocking
ability to use the described solution.
* 25% less time consumed; tests were performed about a year ago
[2012-10-26 16:09:57] dagguh at gmail dot com
What you are referring to is a utility class.
It only has static members and a private constructor, which should never be
called (even from the class itself).
Your suggestion could be useful, because implementing private empty
constructors
is just boilerplate code.
PS. Some people even throw an exception inside the private constructor.
[2009-10-31 00:27:53] cscott at ggot dot org
For Relevancy: I do not believe that namespaces solve this problem, as
__autoload does not work with namespaces (and, for obvious reasons,
shouldn't).
[2009-04-14 21:07:14] cscott at ggot dot org
Description:
Fairly simple: A developer is allowed to define his/her classes as abstract or
final, but not as static. For continuity's sake, it would be preferable to be
able to declare classes as static as well. This would greatly ease the
creation of static function collections/libraries, especially those included
with __autoload().
When a class is declared as abstract, it is a statement at the open that this
is an incomplete member; you can specify any method inside a class to be
abstract and the class is effectively abstract, yet this keyword is allowed in
the class declaration.
When a class is declared final, it is a statement at the open that all members
are to be considered final, and that this class should not be extended any
further.
By allowing classes to be declared as static, it would follow with allowing
abstract class foo in the sense that the keyword reflects the contents of the
class, and would follow with final class foo in that it would define a
binding construct for all members of the class.
Whether
a) In a static class, all methods and members are automatically static
-OR-
b) In a static class, all methods and members must be declared static
Is surely not for me to decide -- either is useful, as it either forces me to
ensure all members are static, or it does the legwork for me. As such, I make
no suggestion and defer to the wisdom of the developer(s).
Thank you for your consideration.
--
Edit this bug report at https://bugs.php.net/bug.php?id=47971edit=1
Req #52657 [Com]: create a spl_object_id function
Edit report at https://bugs.php.net/bug.php?id=52657edit=1
ID: 52657
Comment by: metamarkers at gmail dot com
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:
Here's a chopped down version of my current solution.
function id ( $object ) {
static $id = 0;
if (!isset($object-__id) || $object-__id[0] !== spl_object_hash($object))
{
$object-__id = [spl_object_hash($object),++$id];
}
return $object-__id[1];
}
It works for clones to a degree. Clones can be made through this function to
automatically refresh the id.
function dupe ( $object ) {
$clone = clone $object;
id($clone);
return $clone;
}
Previous Comments:
[2013-09-19 22:29:56] metamarkers at gmail dot com
Could be made into a magic property -__id
The id could just be a signed 64-bit counter that ticks up every time an object
is created. What would happen when you create more than
9,223,372,036,854,775,807
objects? Refactor, probably.
[2013-02-14 12:42:59] maciej dot sz at gmail dot com
An implementation of this is avaliable, and can be compiled as an extension:
http://stackoverflow.com/a/3089587/1697320
[2012-11-15 14:55:08] maciej dot sz at gmail dot com
@rasmus at mindplay dot dk: the thing is PHP already creates internal unique
index for each instantiated object. The requested spl_object_id() function
would only have to return it. You may have seen the value of this variable
while debugging your scripts. Have you not noticed the overhead? ;) Just
kidding.
Anyway, your idea for workaround seemed reasonable to me, and now thanks to the
traits in 5.4 I'm able to apply this unique object id to every class that I
need. Just use the below trait. It is also immune to the __get/__set issue. The
downside of this is that the id is a string containing class name. But if I'd
need an id that is unique only within a specific class scope I can use integer
value without the class name:
?php
/**
* Provides unique object's identifier.
*/
trait TObjectUniqueId
{
/**
* Object's unique id.
*
* @var int
*/
protected $__oid__ = null;
/**
* @return string
*/
public function getObjectUniqueId()
{
static $__object_index = 1;
if ( null === $this-__oid__ ) {
$this-__oid__ = __CLASS__ . '\\' . $__object_index++;
}
return $this-__oid__;
}
}
[2011-06-13 14:28:07] rasmus at mindplay dot dk
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...)
[2011-06-13 10:44:11] marco dot weber at uni-trier dot
Req #10546 [Com]: extract() to work with objects
Edit report at https://bugs.php.net/bug.php?id=10546edit=1
ID: 10546
Comment by: metamarkers at gmail dot com
Reported by:fabiankessler at usa dot net
Summary:extract() to work with objects
Status: Assigned
Type: Feature/Change Request
Package:Class/Object related
Operating System: *
PHP Version:*
Assigned To:andrei
Block user comment: N
Private report: N
New Comment:
A blind import into an object would be neat for shortcutting certain things,
but
would undermine __set(). Consider instead:
function import ( $object , array $vars ) {
foreach ($vars as $k=$v) {
$object-$k = $v;
}
}
Previous Comments:
[2001-04-29 01:06:34] fabiankessler at usa dot net
example:
class foo {
function foo() {
$var_array = array('hello'='world');
extract($var_array, EXTR_PREFIX_ALL, this-prefix);
echo $this-prefix_hello;
}
};
$f = new foo();
:)
fab
--
Edit this bug report at https://bugs.php.net/bug.php?id=10546edit=1
Bug #63863 [Com]: DateTime:setDate() date not used after modify(last day of...)
Edit report at https://bugs.php.net/bug.php?id=63863edit=1
ID: 63863
Comment by: php at seven dot net dot nz
Reported by:brian dot feaver at sellingsource dot com
Summary:DateTime:setDate() date not used after modify(last
day of...)
Status: Open
Type: Bug
Package:Date/time related
Operating System: Mac OS X
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
Confirmed still a bug in 5.5.4 on Mac OS X.
Previous Comments:
[2013-08-02 00:38:48] f21 dot groups at gmail dot com
I am also seeing this in PHP 5.5.1 on Ubuntu 13.04 x64.
[2013-04-04 17:03:08] armin at fruux dot com
Besides from being able to reproduce this completely, it also happens
when using setTimestamp(), as the day keeps being 'last day of month'.
PHP version: 5.4.9
OS: Mac OS X
Test script:
?php
$date = new DateTime('2012-03-30');
$date-modify(last day of last month);
var_dump($date-format('Y-m-d')); // correctly last day of Feb
$date-setTimestamp(1327881600); // 2012-01-30
var_dump($date-format('Y-m-d')); // incorrect date
$date-modify('2012-01-30');
var_dump($date-format('Y-m-d')); // does set correct date
[2012-12-27 18:52:32] brian dot feaver at sellingsource dot com
Description:
When modifying a DateTime object with modify(last day of last month) syntax
and
followed by a setDate(), the date portion of setDate() is ignored. It modifies
the
year and the month, but continues to set the day portion to the last day of the
month.
If modify() is called with the absolute date instead of setDate(), it correctly
sets the date.
Test script:
---
?php
$date = new DateTime('2012-03-30');
$date-modify(last day of last month);
var_dump($date-format('Y-m-d')); // correctly last day of Feb
$date-setDate(2012, 1, 30);
var_dump($date-format('Y-m-d')); // incorrect date
$date-modify('2012-01-30');
var_dump($date-format('Y-m-d')); // does set correct date
Expected result:
string(10) 2012-02-29
string(10) 2012-01-30
string(10) 2012-01-30
Actual result:
--
string(10) 2012-02-29
string(10) 2012-01-31
string(10) 2012-01-30
--
Edit this bug report at https://bugs.php.net/bug.php?id=63863edit=1
Bug #53287 [Com]: PDO 5 Byte write to a broken pipe when forked
Edit report at https://bugs.php.net/bug.php?id=53287edit=1 ID: 53287 Comment by: bryan at esited dot com Reported by:bryan dot tong at gigenet dot com Summary:PDO 5 Byte write to a broken pipe when forked Status: Not a bug Type: Bug Package:PDO related Operating System: CentOS 5.5 x86-64 PHP Version:5.3SVN-2010-11-10 (snap) Assigned To:mysql Block user comment: N Private report: N New Comment: Hello, I wanted to note that a common mysql configuration error will cause this issue. Try changing the following. wait_timeout=60 to wait_timeout=3600 This is located in the /etc/mysql/my.cnf Basically the wait_timeout value should equal that of client_max_read_timeout in NGINX. Hopefully this will help someone else correct the issue. Thanks Previous Comments: [2012-03-06 01:17:11] johan...@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 [2011-01-31 10:42:56] bryan dot tong at gigenet dot com Though it can really make parsing the output a pain when there are multiple versions of mysqlnd floating about. [2011-01-31 10:27:42] u...@php.net This does not smell like an error rather more like mysqlnd being more verbose. No bug, a feature, I'd say. [2010-12-05 21:23:46] seza at paradoxal dot org I have the same error message with php.5.3.3 (send of 5 bytes failed with errno=32 Broken pipe) but in a different context more simply to reproduce : I have a simple website (no fork or stuff like that). It make persistent connection with pdo to mysql (mysqlnd). The errors are raised when the mysql is server is restarted. When mysql server is off error message are mysql server is gone away. No problem with that but once the mysql server is restarted and during 15 minutes I have sometimes this error message (send of 5 bytes failed with errno=32 Broken pipe). Certainly a reuse of a cached connection to mysql before it was restarted. PS : I use mysql_sock connection (mysql:unix_socket=/var/run/mysqld/mysqld.sock) [2010-11-26 13:19:45] johan...@php.net The description mentions forking, the sample code not. Please provide a complete script showing the issue. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53287 -- Edit this bug report at https://bugs.php.net/bug.php?id=53287edit=1
[PHP-BUG] Req #65718 [NEW]: __inClone() magic method to alter an object's inclusion in clones
From: metamarkers at gmail dot com
Operating system:
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:__inClone() magic method to alter an object's inclusion in
clones
Description:
It would be nice if an object could determine whether or not it should be
included in a clone, by returning a value that should be used in its stead,
or an
updated clone of itself, or anything of the like.
Test script:
---
class Foo { }
class Bar {
public function __inClone ( $clone ) {
return $clone instanceof Foo ? null : $this;
}
}
$foo = new Foo();
$foo-bar = new Bar();
$foo2 = clone $foo;
isset($foo2-bar); // false
--
Edit bug report at https://bugs.php.net/bug.php?id=65718edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65718r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65718r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65718r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65718r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65718r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65718r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65718r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65718r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65718r=support
Expected behavior: https://bugs.php.net/fix.php?id=65718r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65718r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65718r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65718r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65718r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65718r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65718r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65718r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65718r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65718r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65718r=mysqlcfg
[PHP-BUG] Req #65719 [NEW]: Register callbacks to an object's lifespan.
From: metamarkers at gmail dot com
Operating system:
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:Register callbacks to an object's lifespan.
Description:
There already exists __destruct(), but if you need to clean up mappings
that use
an object's identifier to cache results etc, there isn't a smooth way of
doing
this.
It would be nice to tie a callback to an object's lifespan.
The catch would of course be that you can't reference the object in the
callback
because of circular references, or maybe you can, I'm not that intimate
with
PHP's garbage collection.
Test script:
---
$x = (object)[];
register_destructor($x,function($x){
// extra cleanup operations with $x,
// or instead an spl_object_hash() could be precalculated and closed
over
// if using $x would cause circular death
});
--
Edit bug report at https://bugs.php.net/bug.php?id=65719edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65719r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65719r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65719r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65719r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65719r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65719r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65719r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65719r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65719r=support
Expected behavior: https://bugs.php.net/fix.php?id=65719r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65719r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65719r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65719r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65719r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65719r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65719r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65719r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65719r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65719r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65719r=mysqlcfg
Req #65718 [Opn-Wfx]: __inClone() magic method to alter an object's inclusion in clones
Edit report at https://bugs.php.net/bug.php?id=65718edit=1
ID: 65718
Updated by: requi...@php.net
Reported by:metamarkers at gmail dot com
Summary:__inClone() magic method to alter an object's
inclusion in clones
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Class/Object related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
That decision should be up to Foo, not up to Bar. If Foo is unaware that it no
longer has a $bar member then that could introduce all sorts of unexpected and
difficult to trace bugs.
Besides, PHP does not do deep copies during cloning anyways.
Implement Foo::__clone() such that it would normally clone all its members.
Then
you can
(a) Make it not clone its $bar and instead unset() it
(b) Implement a private Bar::__clone() so attempting to clone $bar raises a
fatal
Call to private Bar::__clone from context 'Foo'
(c) Implement a public Bar::__clone() and throw an Exception so attempting to
clone $bar fails
Whichever way, Foo is responsible for knowing that Bar cannot be cloned and
should
adjust its own behavior accordingly.
Previous Comments:
[2013-09-20 03:50:39] metamarkers at gmail dot com
Description:
It would be nice if an object could determine whether or not it should be
included in a clone, by returning a value that should be used in its stead, or
an
updated clone of itself, or anything of the like.
Test script:
---
class Foo { }
class Bar {
public function __inClone ( $clone ) {
return $clone instanceof Foo ? null : $this;
}
}
$foo = new Foo();
$foo-bar = new Bar();
$foo2 = clone $foo;
isset($foo2-bar); // false
--
Edit this bug report at https://bugs.php.net/bug.php?id=65718edit=1
Req #65717 [Com]: stat() should supply nano second granularity
Edit report at https://bugs.php.net/bug.php?id=65717edit=1 ID: 65717 Comment by: metamarkers at gmail dot com Reported by:addw at phcomp dot co dot uk Summary:stat() should supply nano second granularity Status: Open Type: Feature/Change Request Package:Filesystem function related Operating System: Any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: What would be a use case of this? Is there something inherently wrong with unix timestamps? Hardware has millisecond latency, I don't understand where having granularity down to the CPU cycle would be significant. Previous Comments: [2013-09-19 21:54:21] addw at phcomp dot co dot uk Description: Some systems (eg Linux on kernel 2.5.48) the 3 timestamp fields may be available with resolution of nanosecond. If these are available stat() should return in the array 3 extra members : atimensec, ctimensec and mtimensec. The resolution available also depends on the underlying file system. -- Edit this bug report at https://bugs.php.net/bug.php?id=65717edit=1
Req #65718 [Com]: __inClone() magic method to alter an object's inclusion in clones
Edit report at https://bugs.php.net/bug.php?id=65718edit=1
ID: 65718
Comment by: metamarkers at gmail dot com
Reported by:metamarkers at gmail dot com
Summary:__inClone() magic method to alter an object's
inclusion in clones
Status: Wont fix
Type: Feature/Change Request
Package:Class/Object related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Valid points. Thanks for reading.
Previous Comments:
[2013-09-20 04:10:47] requi...@php.net
That decision should be up to Foo, not up to Bar. If Foo is unaware that it no
longer has a $bar member then that could introduce all sorts of unexpected and
difficult to trace bugs.
Besides, PHP does not do deep copies during cloning anyways.
Implement Foo::__clone() such that it would normally clone all its members.
Then
you can
(a) Make it not clone its $bar and instead unset() it
(b) Implement a private Bar::__clone() so attempting to clone $bar raises a
fatal
Call to private Bar::__clone from context 'Foo'
(c) Implement a public Bar::__clone() and throw an Exception so attempting to
clone $bar fails
Whichever way, Foo is responsible for knowing that Bar cannot be cloned and
should
adjust its own behavior accordingly.
[2013-09-20 03:50:39] metamarkers at gmail dot com
Description:
It would be nice if an object could determine whether or not it should be
included in a clone, by returning a value that should be used in its stead, or
an
updated clone of itself, or anything of the like.
Test script:
---
class Foo { }
class Bar {
public function __inClone ( $clone ) {
return $clone instanceof Foo ? null : $this;
}
}
$foo = new Foo();
$foo-bar = new Bar();
$foo2 = clone $foo;
isset($foo2-bar); // false
--
Edit this bug report at https://bugs.php.net/bug.php?id=65718edit=1
Bug #65191 [Com]: Delete, ctrl+ arrows don't work in interactive interpreter
Edit report at https://bugs.php.net/bug.php?id=65191edit=1 ID: 65191 Comment by: pippo at gmail dot com Reported by:azhdanov at terricone dot com Summary:Delete, ctrl+ arrows don't work in interactive interpreter Status: Not a bug Type: Bug Package:*General Issues Operating System: Linux PHP Version:5.4.16 Block user comment: N Private report: N New Comment: @cataphract: Thanks, your tip - for DELETE key - run fine! $ cat ~/.editrc bind \e[3~ ed-delete-next-char Previous Comments: [2013-07-03 17:58:48] cataphr...@php.net Not a PHP bug. Configure .editrc (for libedit) or .inputrc (for readline). For instance, I see that ubuntu compiles PHP against libedit, so for instance to have DEL to work you could edit your ~/.editrc and add: bind \e[3~ ed-delete-next-char or just use default shortcuts here: http://www.bigsmoke.us/readline/shortcuts Those are valid for both libedit and readline. My guess is that irc, ipython etc. are compiled against readline and your distros provide a global /etc/inputrc where the bindings are defined. [2013-07-03 08:33:02] azhdanov at terricone dot com Description: When running PHP interactive interpreter with: php -a Delete button doesn't work (produces `~` instead), jumping over words with Ctrl+Left Arrow and Ctrl+Right Arrow doesn't work either (`;5D` and `;5C`, respectively). It annoys me a lot - I use `php -a` every day. Worth noting, that other interpreters (irb, ipython, etc.) work good. The problem occurs in each distro I tried - (K)Ubuntu (PHP 5.4.9-4ubuntu2.1 (cli) (built: Jun 11 2013 13:10:01)), Fedora (PHP 5.3.3 (cli) (built: Nov 29 2012 04:12:23)), RHEL (PHP 5.3.3 (cli) (built: Nov 29 2012 04:12:23)). Works good on Mac though. Expected result: Ctrl+arrows should move the cursor by words, delete should delete current character. Actual result: -- Ctrl+left arrow produces ;5D Ctrl+right arrow produces ;5C Delete produces ~ -- Edit this bug report at https://bugs.php.net/bug.php?id=65191edit=1
