from:"re...@php.net"

Bug #64235 [Com]: Insteadof not work for class method in 5.4.11

2013-02-20 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=64235&edit=1

 ID: 64235
 Comment by:     re...@php.net
 Reported by:imenem at inox dot ru
 Summary:Insteadof not work for class method in 5.4.11
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian GNU/Linux
 PHP Version:5.4.11
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

currently using class in context of trait 'as' and 'inteadof'
didn't work most of the time (as the code below demonstrated, even after apply 
the patch
larucence attached). Only the use case of this bug report, it HAPPENED to work. 


To keep the BC of the problem reported, as I suggested in the previous patch we 
could 
mark it as deprecated in 5.4.

So forbid class in 'as' and 'insteadof' didn't break because most of them 
didn't even work.

in the case of parent class insteadof usage, the REAL need is avoid trait's 
method overwrite
the method inherited but not refer to parent class.

there is a really easy workaround: rename the conflict method as
a new one `Traits::method as _use_less` or something else, 
if we really need the method from parent.


 undefined 
method
StandAlone::foo as bar; // Child::bar() -> undefined method
StandAlone::foo as foo; // Child::foo() -> "Trait"
GrandParent::foo as bar; // Child::bar() -> undefined method

/* insteadof */
Parent::foo insteadof T; // works by accident -> "Parent"
GrandParent::foo insteadof T; // -> "Parent" but not "Grand"
StandAlone::foo insteadof T; // ->"Parent"
}
}


Previous Comments:

[2013-02-20 14:40:32] larue...@php.net

@Stefan the current patch is allow use insteadof with classes (as the reporter 
said, it used to works), 

and forbid use "as" with classes (5.4.11 will result in an unexpected FATAL 
error "undefined method", which is very confused message), the new solution is 
trigger compiler ERROR

so, for the current patch, I think it is consistent with before, no need to be 
RFCed again.

however, if we decide to forbind using both 'as' and 'insteadof' with classes, 
that definitely need a RFC


[2013-02-20 13:20:15] g...@php.net

Hi:

The `insteadof` and `as` operators where not intended to be used with classes.
The syntax is intended to convey that the use operation is refined by 
specifying how to 
resolve conflicts __between__ traits.
That's the idea at least.

My solution for the initial problem presented would be to provide a method such 
as follows in 
the TestChildClass:
  public function method() {
parent::method();
  }

I understand that this is not ideal, and requires you to repeat yourself.
However, it is consistent in the sense that traits are traits and not classes, 
and both get 
mixed up as little as possible,

However, beside the academic notion of purity, I can see that 
`TestParentClass::method 
insteadof TestTrait;` is useful.
[I wonder whether `parent::method insteadof TestTrait;` should be supported as 
well.]


Laruence's example with `TestParentClass::method as methodParent;` is however 
problematic. 
Traits are not supposed to conflict with classes, but with traits. So, allowing 
the 
introduction of aliases for method of the super class seems to me as something 
that is 
problematic, because it mixes up the concepts.

If you need an alias for the method of a parent class, the classic way would be:

public function foo() {
  parent::bar();
}

No?


Well, that's my point of view.


So, from a practical point of view, referring to the parent (and only the 
direct parent) class 
in `insteadof` might be a useful/acceptable feature.
The use in conjunction with `as` seems to be something I would advocate against.
In either way, beside bugs that made this possible in the first place, I would 
consider both 
ideas as new features that need to be documented/discussed.

I thought that we had a test that only the traits listed in the `use` clause 
can be used for 
the `as`/`insteadof` operators, but that's either broken or not there, or a bug 
that was fixed 
in 5.4.11 as the original report suggests.
Therefore, from my perspective, 5.4.11 shows the behavior that's intended by 
the spec/RFC.

Best regards
Stefan

--------
[2013-02-20 08:22:01] larue...@php.net

reeze, *before* doesn't always means *RIGHT*.


[2013-02-20 08:16:52] re...@php.net

@la

Req #64319 [PATCH]: max_input_vars warning unknown file

2013-02-28 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=64319&edit=1

 ID: 64319
 Patch added by:     re...@php.net
 Reported by:david at davidsteinsland dot net
 Summary:max_input_vars warning unknown file
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   CentOS
 PHP Version:5.4.12
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: display-the-requested-script-file-name
Revision:   1362075497
URL:
https://bugs.php.net/patch-display.php?bug=64319&patch=display-the-requested-script-file-name&revision=1362075497


Previous Comments:

[2013-02-28 12:59:09] david at davidsteinsland dot net

Description:

When PHP raises a warning about max_input_vars being exceeded, it would be very 
helpful to see which file actually caused the error. The current error message 
just says "Unknown on line 0".

Expected result:

Script file name

Actual result:
--
Unknown file






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64319&edit=1

Bug #64325 [Com]: Issue in automatic $_POST array handling

2013-02-28 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=64325&edit=1

 ID: 64325
 Comment by:     re...@php.net
 Reported by:php at sygmoral dot com
 Summary:Issue in automatic $_POST array handling
 Status: Open
 Type:   Bug
 Package:Arrays related
 Operating System:   Debian
 PHP Version:5.4.12
 Block user comment: N
 Private report: N

 New Comment:

"post_data = {'save[line[]]':'A line with text'}â


do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention? 
array(
   'save' => 
['line' => 
 ['A line with text', 'maybe more lines']
]
); ?


Previous Comments:

[2013-02-28 16:09:49] php at sygmoral dot com

Description:

Php automatically puts POSTed name-value pairs with names ending in [] into 
arrays. Very handy feature! However, I notice issues when more of those square 
brackets are encountered. 

If I send a name like `save[line[]]`, then `save` will be an array and the 
first key in it will be `line[`, instead of `line[]`. It's not that I expect a 
second level of arrays - just that it doesn't strangely remove that last 
bracket. 

So suppose we have the tiny php script below, and I send this with e.g. jquery:
post_data = {'save[line[]]':'A line with text'}

Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text

Test script:
---
print_r(
   $_POST['save']
);

Expected result:

POST: Array
(
[line[]] => A line with text
)

Actual result:
--
POST: Array
(
[line[] => A line with text
)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64325&edit=1

[PHP-BUG] Bug #64340 [NEW]: sockets tests failed

2013-03-02 Thread re...@php.net

Bug #64340 [PATCH]: sockets tests failed

2013-03-02 Thread re...@php.net

Req #49526 [Com]: C# style property get/set syntax

2013-03-02 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=49526&edit=1

 ID: 49526
 Comment by:     re...@php.net
 Reported by:president at basnetworks dot net
 Summary:C# style property get/set syntax
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

@see https://wiki.php.net/rfc/propertygetsetsyntax-v1.2

this RFC failed to win the vote sadly.


Previous Comments:

[2013-01-09 01:36:22] anka17pinky at yahoo dot com

I wish this request was implemented in PHP 5.5 :(

There are so many questions on SO asking for ways to implement readonly 
properties in PHP...


[2012-01-28 01:45:53] phpdev at zerocue dot com

An "as implemented" document has been created here:
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented

Only thing remaining to be implemented is static accessors.


[2010-10-28 00:48:47] rayro at gmx dot de

I also recommend this but i have a little idea too:

1. Most of the time i use get() syntax and I have to write new 
functions for that (or using __call or __set), because i protect the properties 
with private or protected to protect for writing them.
2. Most of all the code is ugly or has limitations using readonly/writeonly 
properties with __get(&$v) or __set($v,&$c) by reference.
3. It is not perfectly clean to write less code with __get or getter/setter if 
only want to protecting them... And less code matters!

I would like to see a new, or 2 new keywords, e.g. "readonly" and "writonly", 
because the code will look smoother and i dont have to make the use of magic 
methods... Or some own designed errors for that...

Now an simple example:
==



( what about is_readable() or is_writable() for that? )
I dont think that these functions will be used, so only Reflection should be 
extended...

and now, instead of the current syntax:
==

$v;
  }
  function __set($v, $c)
  {
if ($v == 'foo') {
  trigger_error('$foo is not writable from this context',E_USER_ERROR);
}
$this->$v = $c;
return true;
  }
}
?>

get/set syntax will be nice but also nasty if only read/writablity is desired...

this can be confusing as this:
==
foo;
}
function __set() {
  trigger_error('$foo is not writable from this context',E_USER_ERROR);
}
  } = 1;
  static protected $bar {
function __get() {
  trigger_error('$bar is not readable from this context',E_USER_ERROR);
}
function __set() {
  $this->bar = 1;
  return true;
}
  } = 2;
}
?>

think about it... many developers will waive the old way or functions like 
getVarname and setVarname... and for all other, getter/setter will be nice as 
described in the rfc...


[2009-09-13 19:56:24] president at basnetworks dot net

For reference, the RFC for this feature request now exists at this URL:

http://wiki.php.net/rfc/propertygetsetsyntax


[2009-09-13 04:24:08] president at basnetworks dot net

Hi Kalle,

Thanks for the information.  I will follow your instructions and start working 
on the RFC over the next week(s).  Also, thanks for the link about the 
Developer Summit, but it does not show the outcome of the discussion, am I able 
to find that anywhere?




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=49526


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=49526&edit=1

Bug #64340 [Com]: sockets tests failed

2013-03-04 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=64340&edit=1

 ID: 64340
 Comment by:     re...@php.net
 Reported by:    re...@php.net
 Summary:sockets tests failed
 Status: Feedback
 Type:   Bug
 Package:Sockets related
 Operating System:   Mac OSX 10.8
 PHP Version:5.5.0alpha5
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Hi, cataphract
   The macro __APPLE_USE_RFC_3542 must be defined before including netinet/in.h,
but not all of the our c files include php_sockets.h in the topmost, but by 
indirectly
include other header files.

eg: 
$ head -n 1 conversions.c
sockaddr_conv.h

$ header -n 5 sockaddr_conv.h
...
#include 
#include "php_sockets.h" /* php_socket */

php_network.h wil be included  before the macro defined. and 
php_network.h has to been included
before php_sockets.h, so I have to  move conversion.h up instead.

in the mean time, in convesion.h   was included before 
php_sockets.h too, so I have to move it 
up to meet the requirement of the macro. 



The current partial patch breaks the build because of missing the left part:

Undefined symbols for architecture x86_64:
  "_from_zval_write_in6_pktinfo", referenced from:
  _init_ancillary_registry in sendrecvmsg.o
  _php_do_setsockopt_ipv6_rfc3542 in sendrecvmsg.o
  "_to_zval_read_in6_pktinfo", referenced from:
  _init_ancillary_registry in sendrecvmsg.o
  _php_do_getsockopt_ipv6_rfc3542 in sendrecvmsg.o
ld: symbol(s) not found for architecture x86_64


Previous Comments:

[2013-03-03 02:55:50] larue...@php.net

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

I commmitted, since reeze doesn't has PHP karma.

please verify the fix.


[2013-03-03 02:53:54] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f2246f352fc01295c370728d68a9bcd2bb546652
Log: Fixed Bug #64340  (sockets tests failed) Patch by Reeze


[2013-03-03 02:53:30] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f2246f352fc01295c370728d68a9bcd2bb546652
Log: Fixed Bug #64340  (sockets tests failed) Patch by Reeze


[2013-03-02 19:19:57] cataphr...@php.net

What's the deal with having changed the header includes order? I don't really 
like having headers that must be included in a specific order, that usually 
means one header depends on another, but fails to include it; if there's 
something that requires the headers to be in a specific order that should be 
fixed instead.

As to rest (the skip and the define for __APPLE_USE_RFC_3542), I see no problem 
with it; you can commit it yourself.

--------
[2013-03-02 18:05:30] re...@php.net

The following patch has been added/updated:

Patch Name: ipv6-pktinfo-and-tiny-test-fix
Revision:   1362247530
URL:
https://bugs.php.net/patch-display.php?bug=64340&patch=ipv6-pktinfo-and-tiny-test-fix&revision=1362247530




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=64340


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64340&edit=1

Bug #61025 [Com]: __invoke() visibility not honored

2013-03-06 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=61025&edit=1

 ID: 61025
 Comment by:     re...@php.net
 Reported by:jpa...@php.net
 Summary:__invoke() visibility not honored
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   *nix
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Hi, I made a patch again 5.5. how about fix it in 5.5?


Previous Comments:

[2012-07-30 02:22:11] willfi...@php.net

johannes - I can commit a fix for this, but at what point should it be 
introduced?


[2012-02-10 22:34:44] johan...@php.net

Yes, the current behavior is wrong. I don't think it should be fixed in 5.3 
though as the fix might break existing code.


[2012-02-09 09:17:23] jpa...@php.net

Description:

__invoke() visibility is not honored when indirectly called as $obj().
It is, when directly called, via $obj->__invoke();

Please, note as well that declaring __invoke() as static works as well, I think 
it shouldn't (nonsense)

Test script:
---
__invoke(); */

Expected result:

Call to private method Bar::__invoke() from context ...

Actual result:
--
Bar






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61025&edit=1

Req #64484 [Com]: [feature request] second auto_prepend_file

2013-03-22 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=64484&edit=1

 ID: 64484
 Comment by:     re...@php.net
 Reported by:spamik at yum dot pl
 Summary:[feature request] second auto_prepend_file
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

If you need the second auto_prepend_file, then you might want the third.

You could set auto_prepend_file to your administrate file and include a
fixed user file path if it exits.


Previous Comments:

[2013-03-22 04:30:12] spamik at yum dot pl

Description:

There is need for second auto_prepend_file for administrative purposes (for 
example hosting providers). It would allow users to still user 
auto_prepend_file 
and hosting to use its own.
Example uses:
a) $_ENV['APPLICATION_ENV'] = $_SERVER["REDIRECT_APPLICATION_ENV"];
(because apache dont pass env to fastcgi, instead it passes it into fastcgi 
protocol)
b) setting open_basedir (it can't be relaxed later on since php 5.3)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64484&edit=1

Bug #65291 [PATCH]: get_defined_constants() causes PHP to crash in a very limited case.

2013-07-19 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=65291&edit=1

 ID: 65291
 Patch added by:     re...@php.net
 Reported by:gregbenner1 at gmail dot com
 Summary:get_defined_constants() causes PHP to crash in a
 very limited case.
 Status: Verified
 Type:   Bug
 Package:Reproducible crash
 Operating System:   CentOS 6.4
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: Patch-for-65291
Revision:   1374292240
URL:
https://bugs.php.net/patch-display.php?bug=65291&patch=Patch-for-65291&revision=1374292240


Previous Comments:

[2013-07-18 20:27:16] ar...@php.net

Program received signal SIGSEGV, Segmentation fault.
add_assoc_zval_ex (arg=0x77fbe4e8, key=0x0, key_len=0, 
value=0x769a7398) at /home/arpad/w/php/php-src/Zend/zend_API.c:1275
1275return zend_symtable_update(Z_ARRVAL_P(arg), key, key_len, 
(void *) &value, sizeof(zval *), NULL);
(gdb) bt
#0  add_assoc_zval_ex (arg=0x77fbe4e8, key=0x0, key_len=0, 
value=0x769a7398)
at /home/arpad/w/php/php-src/Zend/zend_API.c:1275
#1  0x00588a38 in add_constant_info (constant=0xa8df70, 
arg=0x77fbe4e8)
at /home/arpad/w/php/php-src/Zend/zend_builtin_functions.c:1933
#2  0x00585e8a in zend_hash_apply_with_argument (ht=0x99ccb0, 
apply_func=0x5889b0 , 
argument=0x77fbe4e8) at /home/arpad/w/php/php-src/Zend/zend_hash.c:740
#3  0x0058b0b4 in zif_get_defined_constants (ht=, 
return_value=0x77fbe4e8, 
return_value_ptr=, this_ptr=, 
return_value_used=)
at /home/arpad/w/php/php-src/Zend/zend_builtin_functions.c:2023
#4  0x0061a51d in zend_do_fcall_common_helper_SPEC 
(execute_data=0x77f8b060)
at /home/arpad/w/php/php-src/Zend/zend_vm_execute.h:643
#5  0x005d69dc in execute (op_array=0x77fc0c90) at 
/home/arpad/w/php/php-src/Zend/zend_vm_execute.h:410
#6  0x00579a69 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/arpad/w/php/php-src/Zend/zend.c:1315
#7  0x0051a6b8 in php_execute_script (primary_file=0x7fffcee0) at 
/home/arpad/w/php/php-src/main/main.c:2497
#8  0x0061cc44 in do_cli (argc=2, argv=0x7fffe2d8) at 
/home/arpad/w/php/php-src/sapi/cli/php_cli.c:989
#9  0x00418ab3 in main (argc=2, argv=0x7fffe2d8) at 
/home/arpad/w/php/php-src/sapi/cli/php_cli.c:1365


[2013-07-18 17:54:29] gregbenner1 at gmail dot com

Description:

The function get_defined_constants(); (with or without the bool parameter) 
causes 
PHP to segfault when used in the same script as a Class that uses a Trait which 
has the __CLASS__ magic constant somewhere in it.

If you replace __CLASS__ with get_called_class() it works fine.

Test script:
---
https://bugs.php.net/bug.php?id=65291&edit=1

Bug #65291 [Com]: get_defined_constants() causes PHP to crash in a very limited case.

2013-07-19 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=65291&edit=1

 ID: 65291
 Comment by:     re...@php.net
 Reported by:gregbenner1 at gmail dot com
 Summary:get_defined_constants() causes PHP to crash in a
 very limited case.
 Status: Verified
 Type:   Bug
 Package:Reproducible crash
 Operating System:   CentOS 6.4
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

There is one more case  get_defined_constants(true) :)


Previous Comments:

[2013-07-20 03:50:40] re...@php.net

The following patch has been added/updated:

Patch Name: Patch-for-65291
Revision:   1374292240
URL:
https://bugs.php.net/patch-display.php?bug=65291&patch=Patch-for-65291&revision=1374292240


[2013-07-18 20:27:16] ar...@php.net

Program received signal SIGSEGV, Segmentation fault.
add_assoc_zval_ex (arg=0x77fbe4e8, key=0x0, key_len=0, 
value=0x769a7398) at /home/arpad/w/php/php-src/Zend/zend_API.c:1275
1275return zend_symtable_update(Z_ARRVAL_P(arg), key, key_len, 
(void *) &value, sizeof(zval *), NULL);
(gdb) bt
#0  add_assoc_zval_ex (arg=0x77fbe4e8, key=0x0, key_len=0, 
value=0x769a7398)
at /home/arpad/w/php/php-src/Zend/zend_API.c:1275
#1  0x00588a38 in add_constant_info (constant=0xa8df70, 
arg=0x77fbe4e8)
at /home/arpad/w/php/php-src/Zend/zend_builtin_functions.c:1933
#2  0x00585e8a in zend_hash_apply_with_argument (ht=0x99ccb0, 
apply_func=0x5889b0 , 
argument=0x77fbe4e8) at /home/arpad/w/php/php-src/Zend/zend_hash.c:740
#3  0x0058b0b4 in zif_get_defined_constants (ht=, 
return_value=0x77fbe4e8, 
return_value_ptr=, this_ptr=, 
return_value_used=)
at /home/arpad/w/php/php-src/Zend/zend_builtin_functions.c:2023
#4  0x0061a51d in zend_do_fcall_common_helper_SPEC 
(execute_data=0x77f8b060)
at /home/arpad/w/php/php-src/Zend/zend_vm_execute.h:643
#5  0x005d69dc in execute (op_array=0x77fc0c90) at 
/home/arpad/w/php/php-src/Zend/zend_vm_execute.h:410
#6  0x00579a69 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/arpad/w/php/php-src/Zend/zend.c:1315
#7  0x0051a6b8 in php_execute_script (primary_file=0x7fffcee0) at 
/home/arpad/w/php/php-src/main/main.c:2497
#8  0x0061cc44 in do_cli (argc=2, argv=0x7fffe2d8) at 
/home/arpad/w/php/php-src/sapi/cli/php_cli.c:989
#9  0x00418ab3 in main (argc=2, argv=0x7fffe2d8) at 
/home/arpad/w/php/php-src/sapi/cli/php_cli.c:1365


[2013-07-18 17:54:29] gregbenner1 at gmail dot com

Description:

The function get_defined_constants(); (with or without the bool parameter) 
causes 
PHP to segfault when used in the same script as a Class that uses a Trait which 
has the __CLASS__ magic constant somewhere in it.

If you replace __CLASS__ with get_called_class() it works fine.

Test script:
---
https://bugs.php.net/bug.php?id=65291&edit=1

Bug #48795 [Com]: Building intl 64-bit fails on OS X

2012-09-11 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=48795&edit=1

 ID: 48795
 Comment by:     re...@php.net
 Reported by:gwy...@php.net
 Summary:Building intl 64-bit fails on OS X
 Status: Verified
 Type:   Bug
 Package:Compile Failure
 Operating System:   OS X 10.5 & 10.6; Linux
 PHP Version:5.3 SVN; 5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

Same for me, I can't compile either. hope there is a solution


Previous Comments:

[2012-05-08 13:11:12] k...@php.net

Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A 
generic solution would be nice, indeed.


[2012-03-13 15:46:33] dan at cdchase dot com

It would be helpful if the build system imported any already set CFLAGS. As 
I've experienced this issue before, so I've set the appropriate CFLAGS in my 
default environment. But, the automated install routine does not honor these. I 
have to manually install for them to be honored.


[2011-11-14 16:54:00] weierophin...@php.net

I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1 
on linux 64-bit.


[2011-11-11 11:30:21] ahar...@php.net

tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with
./configure --enable-intl --with-curl.


Effectively the same issue (required C++ linkage not occurring) is now
happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with
PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl
enabled (note that a compile with just --enable-intl succeeds). It's
notable that both these distributions feature the new Debian
"multiarch" support. Both libcurl and libicu are the normal packaged
versions.

With ./configure --enable-intl --with-curl, the result of
the compile (on the Ubuntu box, although the Debian errors are
effectively the same, just with different architecture-specific paths)
is this:

/usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to 
symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command 
line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid 
operation
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1

Diffing the Makefile produced by --enable-intl alone with the
"--enable-intl --with-curl" combination produces the following
(excluding rules directly related to compiling objects within
ext/curl):

@@ -75,9 +76,9 @@
 CXXFLAGS_CLEAN = -g -O2
 DEBUG_CFLAGS =
 EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-EXTRA_LDFLAGS =
-EXTRA_LDFLAGS_PROGRAM =
-EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2 
-ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2 
-lxml2 -lxml2 -lcrypt
+EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2 
-lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 
-lcrypt -lxml2 -lxml2 -lxml2 -lcrypt
 ZEND_EXTRA_LIBS =
 INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex 
-I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite 
-I$(top_builddir)/TSRM -I$(top_builddir)/Zend
 EXTRA_INCLUDES =
@@ -86,13 +87,13 @@
 LFLAGS =
 LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
 LN_S = ln -s
-NATIVE_RPATHS =
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
 PEAR_INSTALLDIR = ${exec_prefix}/lib/php
 PHP_BUILD_DATE = 2011-11-11
-PHP_LDFLAGS =
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
 PHP_LIBS =
 OVERALL_TARGET =
-PHP_RPATHS =
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
 PHP_SAPI = none
 PHP_VERSION = 5.4.0RC1
 PHP_VERSION_ID = 50400

Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the
build.

I'm not familiar enough with our build system to know how to fix this,
but we should probably do something if we can for 5.4.0 final: intl
and curl doesn't seem like it would be an unusual combination. Can we
hack the build system to use the C++ compiler preferentially if
ext/intl and ext/curl are enabled, if it can't be fixed "properly"
(whatever form that takes -- it may even up being an upstream issue)?


[2011-11-06 19:11:09] luke at cywh dot com

Is there going to be a

Bug #52909 [Com]: ReflectionMethod::getParameters() return incorrect number of arguments

2012-09-11 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=52909&edit=1

 ID: 52909
 Comment by:     re...@php.net
 Reported by:frederic dot hardy at mageekbox dot net
 Summary:ReflectionMethod::getParameters() return incorrect
 number of arguments
 Status: Assigned
 Type:   Bug
 Package:PHAR related
 Operating System:   FreeBSD 8.0
 PHP Version:5.3.3
 Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

Hi aharvey
   reopen and what to do next :)


Previous Comments:

[2010-09-23 17:37:05] ahar...@php.net

Reopening per IRC discussion.


[2010-09-23 06:52:42] ahar...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2010-09-23 06:52:32] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=303712
Log: Fix doc bug #52909 by documenting the extra parameters available in
PharData::__construct().


[2010-09-23 06:41:17] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=303709
Log: Fix up the vim folds in phar_object.c and add a note that the two 
prototypes
before Phar::__construct() are actually valid and not a mistake, per bug
#52909.


[2010-09-23 06:39:18] ahar...@php.net

The reason for this is that Phar and PharData actually use the same function 
for their __construct implementations -- internally it calls 
instanceof_function() to figure out whether it's constructing a Phar or 
PharData object and then has some if statements to handle things from there. 
There's no distinct arginfo for the PharData implementation, so reflection has 
no way of distinguishing the three parameter Phar constructor from the four 
parameter PharData constructor.

I'll make the proto comment in phar_object.c a little clearer (and remove the 
extra vim fold that doesn't do anything useful). Beyond that, the manual's 
correct for Phar::__construct() but not for PharData::__construct() (which is 
currently documented as accepted two parameters when it actually accepts four), 
so I'll fix that up.

I don't see any way of getting reflection to do the right thing short of 
refactoring the function into two -- which might be the right thing to do 
anyway, but is a decision for Greg or Marcus to make.




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=52909


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=52909&edit=1

Req #40457 [Com]: ReflectionProperty lacks method getStartLine() / getEndLine()

2012-09-11 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=40457&edit=1

 ID: 40457
 Comment by:     re...@php.net
 Reported by:ralph at smashlabs dot com
 Summary:ReflectionProperty lacks method getStartLine() /
 getEndLine()
 Status: Open
 Type:   Feature/Change Request
 Package:Reflection related
 Operating System:   Linux 2.6
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

I like the idea, but those information didn't exists in runtime as 
class/functions
just for this request to implement this seems a waste.


Previous Comments:

[2010-07-27 22:09:52] rasmus at mindplay dot dk

Yes, this is missing for me too. Badly.

Trying to work around this by manually scanning the source code for the 
property definition would be a huuuge PITA... :-(


[2007-02-13 04:40:08] ralph at smashlabs dot com

Description:

Simply put, when getting a property (in the same manner as a method) from a 
class, ReflectionProperty lacks the ability (as does the ReflectionClass) to 
retrieve a line number from where the property was defined.

  - Properties [1] {
Property [  protected $_Id ]
  }

  - Methods [3] {
Method [  public method get ] {
  @@ 
/home/webdeveloper/vhosts/zdiis2.dev/development/modeling/models/ZDISubmission.php
 11 - 14

  - Parameters [1] {
Parameter #0 [  $identifiers = Array ]
  }
}







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=40457&edit=1

Req #53573 [Com]: Invisible "static" property of Closure

2012-09-11 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=53573&edit=1

 ID: 53573
 Comment by:     re...@php.net
 Reported by:kak dot serpom dot po dot yaitsam at gmail dot com
 Summary:Invisible "static" property of Closure
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.4
 Block user comment: N
 Private report: N

 New Comment:

In fact, closure is a class: Closure just an implementation detail.

we should forget about the class itself. the output static is just 
let you to ease debugging but not for public access


Previous Comments:

[2011-02-16 02:04:21] olamedia at gmail dot com

Please, let Closure be standard object without any restrictions.
Let developers decide what they can use, and what must not.
PHP is already full enough of "RESERVED" "YOU MUST NOT" "YOU CAN NOT" "YOU 
SHOULD 
NOT" "ITS HARD, SO WE WILL NOT MAKE THIS FEATURE" "I DONT NEED THIS, SO PLEASE 
DON'T REQUEST THIS FEATURE"


[2011-02-16 01:51:07] olamedia at gmail dot com

c[$name]; // example
$self = $this;
// how can I pass $self to closure?
$closure->static['self'] = $this // NO!, Reflection is giving empty array
call_user_func_array($closure, $args);
  }
}
$a = new a();
$a->c['hello'] = function($x) use ($self){
  return 'Hello, '.$x.'! My name is '.get_class($self).'!';
};
$a->hello('php');


[2010-12-19 06:03:08] kak dot serpom dot po dot yaitsam at gmail dot com

Description:

var_dump($closure) displays public property named "static", but I cannot access 
to 
it with standard call: Closure object cannot have properties
It might be very useful!
Thanks.

Test script:
---
{'static'}['foo'] = 'foo';
$a();


Expected result:

Output: foo

Actual result:
--
object(Closure)#1 (1) {
  ["static"]=>
  array(1) {
["foo"]=>
string(3) "bar"
  }
}
PHP Catchable fatal error:  Closure object cannot have properties in 
/home/web/1.php on line 7







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53573&edit=1

Bug #62852 [Com]: Unserialize Invalid Date causes crash

2012-09-14 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=62852&edit=1

 ID: 62852
 Comment by:     re...@php.net
 Reported by:kasper at webmasteren dot eu
 Summary:Unserialize Invalid Date causes crash
 Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   windows, linux
 PHP Version:Irrelevant
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Yeah, the segfault is bad.

but the test script is wired, why do you want to refer to it before wakeup?

When construct the DateTime if invalid date it throw exception, so
when unserialize from an invalid date throw exception is reasonable.


Previous Comments:

[2012-09-15 03:33:26] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"


[2012-09-15 03:32:53] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"


[2012-09-15 03:30:56] larue...@php.net

@tstarling  okey, I reverted. and make the test XFAIL for now, we should fix 
this 
in another way.


[2012-09-15 03:30:07] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"


[2012-09-14 21:22:38] tstarl...@php.net

The suggested patch does not fix the bug. Throwing an exception does not ensure 
destruction of the object. For example, you can override __wakeup() in a 
derived class and put a reference to the half-initialised object in a global 
value before calling DateTime::__wakeup(). Full test case at 

http://tstarling.com/stuff/bad-date.phps

It segfaults for me on today's git master. It looks to me like either 
dateobj->time should be fully initialised, or it should be set back to NULL so 
that DATE_CHECK_INITIALIZED() etc. will guard accesses.

In my opinion, throwing an exception from unserialize() is an unnecessary b/c 
break and should be reverted.




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=62852


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1

Bug #62852 [PATCH]: Unserialize Invalid Date causes crash

2012-09-15 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=62852&edit=1

 ID: 62852
 Patch added by:     re...@php.net
 Reported by:kasper at webmasteren dot eu
 Summary:Unserialize Invalid Date causes crash
 Status: Re-Opened
 Type:   Bug
 Package:Reproducible crash
 Operating System:   windows, linux
 PHP Version:Irrelevant
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: Fix-add-exception-checking
Revision:   1347761929
URL:
https://bugs.php.net/patch-display.php?bug=62852&patch=Fix-add-exception-checking&revision=1347761929


Previous Comments:

[2012-09-15 06:57:20] larue...@php.net

closed by commit email, reopen


[2012-09-15 04:26:07] re...@php.net

Yeah, the segfault is bad.

but the test script is wired, why do you want to refer to it before wakeup?

When construct the DateTime if invalid date it throw exception, so
when unserialize from an invalid date throw exception is reasonable.


[2012-09-15 03:33:26] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"


[2012-09-15 03:32:53] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"


[2012-09-15 03:30:56] larue...@php.net

@tstarling  okey, I reverted. and make the test XFAIL for now, we should fix 
this 
in another 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

https://bugs.php.net/bug.php?id=62852


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1

Bug #62852 [Com]: Unserialize Invalid Date causes crash

2012-09-15 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=62852&edit=1

 ID: 62852
 Comment by:     re...@php.net
 Reported by:kasper at webmasteren dot eu
 Summary:Unserialize Invalid Date causes crash
 Status: Re-Opened
 Type:   Bug
 Package:Reproducible crash
 Operating System:   windows, linux
 PHP Version:Irrelevant
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

@tstarling the partially initialize problem could be fixed by adding
and exception checking. (the attache patch is a fix for this)

As the exception throwing, I think it's not bc break, since before
the fix, it will just crash, fix the crash is not bc break, and
the use could define __walkup method, it may throw exception too,
so I think throw exception won't make unserialize inconsistant.

Just my 2 cents;


Previous Comments:

[2012-09-16 02:18:49] re...@php.net

The following patch has been added/updated:

Patch Name: Fix-add-exception-checking
Revision:   1347761929
URL:
https://bugs.php.net/patch-display.php?bug=62852&patch=Fix-add-exception-checking&revision=1347761929


[2012-09-15 06:57:20] larue...@php.net

closed by commit email, reopen


[2012-09-15 04:26:07] re...@php.net

Yeah, the segfault is bad.

but the test script is wired, why do you want to refer to it before wakeup?

When construct the DateTime if invalid date it throw exception, so
when unserialize from an invalid date throw exception is reasonable.


[2012-09-15 03:33:26] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"


[2012-09-15 03:32:53] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"




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=62852


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1

Bug #62852 [Com]: Unserialize Invalid Date causes crash

2012-09-15 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=62852&edit=1

 ID: 62852
 Comment by:     re...@php.net
 Reported by:kasper at webmasteren dot eu
 Summary:Unserialize Invalid Date causes crash
 Status: Re-Opened
 Type:   Bug
 Package:Reproducible crash
 Operating System:   windows, linux
 PHP Version:Irrelevant
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

@laruence, What do you think about this, if you have any better solutions
will be much appreciated :)


Previous Comments:

[2012-09-16 02:23:42] re...@php.net

@tstarling the partially initialize problem could be fixed by adding
and exception checking. (the attache patch is a fix for this)

As the exception throwing, I think it's not bc break, since before
the fix, it will just crash, fix the crash is not bc break, and
the use could define __walkup method, it may throw exception too,
so I think throw exception won't make unserialize inconsistant.

Just my 2 cents;


[2012-09-16 02:18:49] re...@php.net

The following patch has been added/updated:

Patch Name: Fix-add-exception-checking
Revision:   1347761929
URL:
https://bugs.php.net/patch-display.php?bug=62852&patch=Fix-add-exception-checking&revision=1347761929


[2012-09-15 06:57:20] larue...@php.net

closed by commit email, reopen


[2012-09-15 04:26:07] re...@php.net

Yeah, the segfault is bad.

but the test script is wired, why do you want to refer to it before wakeup?

When construct the DateTime if invalid date it throw exception, so
when unserialize from an invalid date throw exception is reasonable.


[2012-09-15 03:33:26] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7
Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes 
crash)"




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=62852


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1

Bug #62952 [Com]: Methods from ServerClient cannot be used with ReflectionMethod

2012-09-19 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=62952&edit=1

 ID: 62952
 Comment by:     re...@php.net
 Reported by:gabriel dot heming at hotmail dot com
 Summary:Methods from ServerClient cannot be used with
 ReflectionMethod
 Status: Feedback
 Type:   Bug
 Package:Reflection related
 Operating System:   Windows
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

An extra comma was appended to the url, please try this:

https://gist.github.com/3750131

In short:
" The ReflectionMethod class reports information about a method."
if method didn't exists an exception was thrown when construct ReflectionMethod.


Previous Comments:

[2012-09-19 15:08:05] re...@php.net

Hi, 
  since call methods from a webservice like $client->method($args) is
a proxy method, it didn't exist in Soapclient, it use the magic method
Soapclient::__call() to the really work, so th method didn't exist at all

see: https://gist.github.com/3750131, it should been a fatal error complain
method didn't exists.

could you please try the test script from the gist above?


[2012-08-27 14:36:53] gabriel dot heming at hotmail dot com

Description:

Well, I'm trying reflect a client of web service. When I use 
call_user_func_array 
it works fine. But when I use ReflectionMethod, doesn't work. Is better you see:

Test script:
---
My variables:
$client = new SoapClient('http://localhost/webservice?wsdl');
$method = 'someMethod';
arguments = array('argument one' , 'argument two');

This code work fine:
return call_user_func_array(array($client , $method) , $arguments);

This code doesn't work
$reflectionMethod = new ReflectionMethod($client , $method);
return $reflectionMethod->invokeArgs($client , $arguments);

Expected result:

Return of function from ServerClient.


Actual result:
--
Fatal error: Uncaught SoapFault exception: [Client] looks like we got no XML 
document in...






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62952&edit=1

Bug #63104 [Com]: php fail to build with --enable-intl

2012-09-19 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=63104&edit=1

 ID: 63104
 Comment by:     re...@php.net
 Reported by:maduma at pt dot lu
 Summary:php fail to build with --enable-intl
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Solaris 11
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

similar to https://bugs.php.net/bug.php?id=48795 but different platform.


Previous Comments:

[2012-09-19 08:03:59] larue...@php.net

I can not reproduce it:
$php -m | grep intl
intl

$php -r 'proc_open("ls");'
PHP Warning:  proc_open() expects at least 3 parameters, 1 given in Command 
line 
code on line 1


[2012-09-19 07:46:30] maduma at pt dot lu

Still have problems with intl extention. When i compile 5.4 with intl the 
proc_open() function is not defined anymore

# --with-intl
/usr/php/5.4/bin/php -r 'proc_open();'
PHP Fatal error:  Call to undefined function proc_open() in Command line code 
on line 1

# without intl
/usr/php/5.4/bin/php -r 'proc_open();'
PHP Warning:  proc_open() expects at least 3 parameters, 0 given in Command 
line code on line 1


[2012-09-18 11:09:26] maduma at pt dot lu

Need also to create libCstd.so and libCrun.so link

ln -s /usr/lib/libCstd.so.1 /usr/lib/libCstd.so
ln -s /usr/lib/libCrun.so.1 /usr/lib/libCrun.so


[2012-09-18 07:52:33] maduma at pt dot lu

It seems that the build use g++ compiler for c++ and cc for c compiler
I've now defined cc and CC env variable

cc=/opt/solarisstudio12.3/bin/cc CXX=/opt/solarisstudio12.3/bin/CC \
./configure --prefix=/usr/php/5.4 --sysconfdir=/etc/php/5.4 \
--mandir=/usr/php/5.4/man --with-config-file-path=/etc/php/5.4 \
--enable-intl

The build failed also in the linker

/bin/sh /root/php/php-5.4.7/libtool --silent --preserve-dup-deps --mode=link cc 
-export-dynamic -I/usr/include -O -xs -xstrconst -zlazyload -xmemalign=8s 
ext/date/php_date.lo ...  -lstdc++ -lrt -lm -lnsl -lsocket -lxml2 -lz -lm 
-lsocket -lnsl -lxml2 -lz -lm -lsocket -lnsl -lCrun -lCstd -lm -licui18n 
-licuuc -licudata -lm -licuio -lxml2 -lz -lm -lsocket -lnsl -lxml2 -lz -lm 
-lsocket -lnsl -lxml2 -lz -lm -lsocket -lnsl -lxml2 -lz -lm -lsocket -lnsl  -o 
sapi/cli/php
ld: fatal: library -lstdc++: not found
ld: fatal: file processing errors. No output written to sapi/cli/php

Why do the we need stdc++ (g++ related) !
I just removed -lstdc++ and it working now.

Need to test it now


[2012-09-18 07:14:41] maduma at pt dot lu

root@build-sparc:~# icu-config --version
4.6




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=63104


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63104&edit=1

[PHP-BUG] Req #63188 [NEW]: Display class name when debugging with gdb macro zbacktrace

2012-09-29 Thread re...@php.net

From: reeze
Operating system: 
PHP version:  Irrelevant
Package:  Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:Display class name when debugging with gdb macro zbacktrace

Description:

For example, an uncatched exception backtrace and debug_backtrace()
 have class name if it's an method. but when debugging with gdb,
the macro zbacktrace and dump_bt didn't display it.

it would be easier to debug if the class name displayed

just like:
Fatal error: Uncaught exception 'Exception' with message 'NO' in 
/Users/reeze/Opensource/php-test/php-src-5.4/b.php:5
Stack trace:
#0 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(9): A::bar()
#1 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(15): A->foo(1)
#2 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(20): B->foo(1)
#3 {main}
  thrown in /Users/reeze/Opensource/php-test/php-src-5.4/b.php on line 5

Test script:
---
foo(1);


Expected result:

[0x100ca4490] core_me("127.0.0.1")
/Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] A::bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8

[0x100ca42b8] A->foo(1)
/Users/reeze/Opensource/php-test/php-src-5.4/b.php:14 
[0x100ca40e8] B->foo(1)
/Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 

Actual result:
--
[0x100ca4490] core_me("127.0.0.1")
/Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8 
[0x100ca42b8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:14

[0x100ca40e8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 

-- 
Edit bug report at https://bugs.php.net/bug.php?id=63188&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63188&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63188&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63188&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63188&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63188&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63188&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63188&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63188&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63188&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63188&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63188&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63188&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63188&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63188&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63188&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63188&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63188&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63188&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63188&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63188&r=mysqlcfg

Req #63188 [Com]: Display class name when debugging with gdb macro zbacktrace

2012-09-29 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=63188&edit=1

 ID: 63188
 Comment by:     re...@php.net
 Reported by:    re...@php.net
 Summary:Display class name when debugging with gdb macro
 zbacktrace
 Status: Open
 Type:   Feature/Change Request
 Package:Unknown/Other Function
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

A patch was sent here: 
https://github.com/php/php-src/pull/209


Previous Comments:

[2012-09-29 19:17:14] re...@php.net

Description:

For example, an uncatched exception backtrace and debug_backtrace()
 have class name if it's an method. but when debugging with gdb,
the macro zbacktrace and dump_bt didn't display it.

it would be easier to debug if the class name displayed

just like:
Fatal error: Uncaught exception 'Exception' with message 'NO' in 
/Users/reeze/Opensource/php-test/php-src-5.4/b.php:5
Stack trace:
#0 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(9): A::bar()
#1 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(15): A->foo(1)
#2 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(20): B->foo(1)
#3 {main}
  thrown in /Users/reeze/Opensource/php-test/php-src-5.4/b.php on line 5

Test script:
---
foo(1);


Expected result:

[0x100ca4490] core_me("127.0.0.1") /Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] A::bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8 
[0x100ca42b8] A->foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:14 
[0x100ca40e8] B->foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 

Actual result:
--
[0x100ca4490] core_me("127.0.0.1") /Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8 
[0x100ca42b8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:14 
[0x100ca40e8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63188&edit=1

Bug #63248 [Com]: ext\fileinfo\tests\bug61964.phpt fails

2012-10-14 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=63248&edit=1

 ID: 63248
 Comment by:     re...@php.net
 Reported by:a...@php.net
 Summary:ext\fileinfo\tests\bug61964.phpt fails
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4Git-2012-10-09 (Git)
 Block user comment: N
 Private report: N

 New Comment:

I didn't have build environment installed, will try that later :)


Previous Comments:

[2012-10-13 21:16:32] a...@php.net

@reeze, that's exactly what it's about - prevent tries to get dir handle on 
windows. Another part of that is that it was using dirent_a.lib to iterate a 
dir which doesn't work on 5.4 as expected. I've updated the patch where that 
part is implemented with streams. Could you try it on windows please? Was the 
previous patch working for you on windows?


[2012-10-13 21:08:25] a...@php.net

The following patch has been added/updated:

Patch Name: bug63248.patch
Revision:   1350162505
URL:
https://bugs.php.net/patch-display.php?bug=63248&patch=bug63248.patch&revision=1350162505

--------
[2012-10-13 15:36:48] re...@php.net

on windows we couldn't  fopen() or file_get_contents() a directory.
it didn't consist on *nix systems behavior

so does the test failed because of this. 

maybe we could update streams implementation?


[2012-10-11 22:40:08] mattfic...@php.net

Most recent patch fixes the actual problem for me. Test still fails, but I 
don't get any error messages. It fails because the expected warning messages 
are missing.


[2012-10-11 15:53:18] a...@php.net

Updated the patch, using the PHPs readdir implementation win32/readdir.c 
instead of reimlementing it :)




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=63248


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63248&edit=1

[PHP-BUG] Bug #63428 [NEW]: The behavior of execute() changed

2012-11-03 Thread re...@php.net

From: reeze
Operating system: ANY
PHP version:  master-Git-2012-11-03 (Git)
Package:  *General Issues
Bug Type: Bug
Bug description:The behavior of execute() changed

Description:

Test Zend/tests/bug35437.phpt failed because of this when dtrace
enabled or any extension which override zend_execute function pointer,
such as xdebug.


Test script:
---
Test: Zend/tests/bug35437.phpt with dtrace or xdebug enabled

Expected result:

test PASS

Actual result:
--
Test failed because of segfault.

-- 
Edit bug report at https://bugs.php.net/bug.php?id=63428&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63428&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63428&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63428&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63428&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63428&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63428&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63428&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63428&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63428&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63428&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63428&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63428&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63428&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63428&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=63428&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=63428&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63428&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63428&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63428&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=63428&r=mysqlcfg

Bug #64235 [Com]: Insteadof not work for class method in 5.4.11

2013-02-20 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=64235&edit=1

 ID: 64235
 Comment by:     re...@php.net
 Reported by:imenem at inox dot ru
 Summary:Insteadof not work for class method in 5.4.11
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian GNU/Linux
 PHP Version:5.4.11
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

insteadof and 'as' bother for traits, I thought after the trait refactor, it's 
works as expected.

If we keep 'insteadof' could been used for class method as feature I'm fine:0


Previous Comments:

[2013-02-20 07:58:32] dmi...@php.net

Yet another traits mess :(
I suppose, it worked in 5.4.4 because of mistake.
RFC and traits documentation don't say if class names may be used in context of 
"as" and "insteadof" operators.

In my opinion, class names must not be used in contest of "as".
However, their usage in context of "inseadof" may make sense (I'm not sure).
Anyway, it has to be defined in documentation first.


[2013-02-20 07:44:12] larue...@php.net

fix attached, which fix this bug, and trigger fatal error in compile time for 
the 
test script I pasted before.


[2013-02-20 07:41:23] larue...@php.net

The following patch has been added/updated:

Patch Name: bug64235.phpt
Revision:   1361346083
URL:
https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.phpt&revision=1361346083


[2013-02-20 07:39:40] larue...@php.net

The following patch has been added/updated:

Patch Name: bug64235.patch
Revision:   1361345980
URL:
https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.patch&revision=1361345980


[2013-02-20 07:15:37] larue...@php.net

actually, I was looking into this,  I have thought the similar fix of you, but 
unfortunatly, it is wrong, thinking of this:

methodParent();
~




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=64235


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1

Bug #64235 [Com]: Insteadof not work for class method in 5.4.11

2013-02-20 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=64235&edit=1

 ID: 64235
 Comment by:     re...@php.net
 Reported by:imenem at inox dot ru
 Summary:Insteadof not work for class method in 5.4.11
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian GNU/Linux
 PHP Version:5.4.11
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

@laurence  the code you paste above works the same as before:
http://3v4l.org/UpMCW#v5411 that didn't break

After read some doc I assume class is not suitable in context of 'insteadof', 
so let's wait for Stefan or more discussion :)


Previous Comments:

[2013-02-20 08:12:40] larue...@php.net

form the context,  insteadof works at class make sense.

reeze, whatever the RFC is, your fix simply skip check for classes at all, 
which 
will make the test script I paste result in "FATAL ERROR, undefined method", 
that 
is not acceptable.


[2013-02-20 08:07:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug64235.patch
Revision:   1361347678
URL:
https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.patch&revision=1361347678


[2013-02-20 08:04:11] dmi...@php.net

It's hard to say what is expected :)
I thought only traits may be used in context of "insteadof", now I'm not sure.

I sent the question to Stefan Marr. Lets wait for his opinion.

--------
[2013-02-20 08:00:02] re...@php.net

insteadof and 'as' bother for traits, I thought after the trait refactor, it's 
works as expected.

If we keep 'insteadof' could been used for class method as feature I'm fine:0


[2013-02-20 07:58:32] dmi...@php.net

Yet another traits mess :(
I suppose, it worked in 5.4.4 because of mistake.
RFC and traits documentation don't say if class names may be used in context of 
"as" and "insteadof" operators.

In my opinion, class names must not be used in contest of "as".
However, their usage in context of "inseadof" may make sense (I'm not sure).
Anyway, it has to be defined in documentation first.




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=64235


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1

Bug #36759 [Com]: Objects destructors are invoked in wrong order when script is finished

2013-02-20 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=36759&edit=1

 ID: 36759
 Comment by:     re...@php.net
 Reported by:alexander dot v at zend dot com
 Summary:Objects destructors are invoked in wrong order when
 script is finished
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   all
 PHP Version:5CVS-2006-03-16 (snap)
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

I seems been fixed already, see: http://3v4l.org/b2JWc


Previous Comments:

[2011-03-21 03:04:57] tstarling at wikimedia dot org

r216213 fixes that one test case, but it seems like the actual complaint here 
is that objects stored in member variables are destroyed before the objects 
that reference them. I can see three problems with r216213. Two of them mean 
that this bug is not fixed, and the third causes another bug.

1. It assumes that all objects which hold references to other objects will be 
in the global symbol table. For objects that aren't in the global symbol table, 
it fails. For example if you take the test case and replace this:

$y = new Bar();
$x = new Foo($y);

with this:

function foo() {
static $x, $y;
$y = new Bar();
$x = new Foo($y);
}
foo();

then the destructors are called in the wrong order.

2. It only deletes objects which have a reference count of 1. When a zval is 
referred to by two symbol table entries, both symbol table entries point to the 
same zval, and both have a reference count of 2, so neither is deleted. So if 
you replace the same part of the test case with:

$y = new Bar();
$x = new Foo($y);
$z = $x;

then the destructors are called in the wrong order.

3. It deletes variables, instead of just calling __destruct() on them as 
expected. This was a hack to reuse the reference-counting code in 
zval_ptr_dtor(). It's unnecessary and causes several user-visible side effects, 
such as bug #54157.


[2011-03-21 01:35:02] s...@php.net

According to Tim Starling, still happens, details to follow soon.


[2006-07-12 08:57:50] dmi...@php.net

Fixed in CVS HEAD and PHP_5_2.


[2006-03-16 15:12:50] dmi...@php.net

Reproduce code:
---
bar = $bar;
  }
  function __destruct() {
echo __METHOD__,"\n";
unset($this->bar);
  }
}

class Bar {
  function __destruct() {
echo __METHOD__,"\n";
unset($this->bar);
  }
}
$y = new Bar();
$x = new Foo($y);
?>

Expected result:

Foo::__destruct
Bar::__destruct

Actual result:
--
Bar::__destruct
Foo::__destruct




[2006-03-16 15:02:04] alexander dot v at zend dot com

Description:

Object destructors are invoked in an arbitrarily order.
Objects from a global_symbol_table should be destructed first.

Reproduce code:
---
too large and not deterministic

Expected result:

none

Actual result:
--
none






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=36759&edit=1

Bug #36759 [Com]: Objects destructors are invoked in wrong order when script is finished

2013-02-20 Thread re...@php.net

Edit report at https://bugs.php.net/bug.php?id=36759&edit=1

 ID: 36759
 Comment by:     re...@php.net
 Reported by:alexander dot v at zend dot com
 Summary:Objects destructors are invoked in wrong order when
 script is finished
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   all
 PHP Version:5CVS-2006-03-16 (snap)
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Sorry I just try to reproduce, but didn't try the later script.


Previous Comments:

[2013-02-20 09:10:49] re...@php.net

I seems been fixed already, see: http://3v4l.org/b2JWc


[2011-03-21 03:04:57] tstarling at wikimedia dot org

r216213 fixes that one test case, but it seems like the actual complaint here 
is that objects stored in member variables are destroyed before the objects 
that reference them. I can see three problems with r216213. Two of them mean 
that this bug is not fixed, and the third causes another bug.

1. It assumes that all objects which hold references to other objects will be 
in the global symbol table. For objects that aren't in the global symbol table, 
it fails. For example if you take the test case and replace this:

$y = new Bar();
$x = new Foo($y);

with this:

function foo() {
static $x, $y;
$y = new Bar();
$x = new Foo($y);
}
foo();

then the destructors are called in the wrong order.

2. It only deletes objects which have a reference count of 1. When a zval is 
referred to by two symbol table entries, both symbol table entries point to the 
same zval, and both have a reference count of 2, so neither is deleted. So if 
you replace the same part of the test case with:

$y = new Bar();
$x = new Foo($y);
$z = $x;

then the destructors are called in the wrong order.

3. It deletes variables, instead of just calling __destruct() on them as 
expected. This was a hack to reuse the reference-counting code in 
zval_ptr_dtor(). It's unnecessary and causes several user-visible side effects, 
such as bug #54157.


[2011-03-21 01:35:02] s...@php.net

According to Tim Starling, still happens, details to follow soon.


[2006-07-12 08:57:50] dmi...@php.net

Fixed in CVS HEAD and PHP_5_2.


[2006-03-16 15:12:50] dmi...@php.net

Reproduce code:
---
bar = $bar;
  }
  function __destruct() {
echo __METHOD__,"\n";
unset($this->bar);
  }
}

class Bar {
  function __destruct() {
echo __METHOD__,"\n";
unset($this->bar);
  }
}
$y = new Bar();
$x = new Foo($y);
?>

Expected result:

Foo::__destruct
Bar::__destruct

Actual result:
--
Bar::__destruct
Foo::__destruct






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=36759


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=36759&edit=1

Bug #64235 [Com]: Insteadof not work for class method in 5.4.11

Req #64319 [PATCH]: max_input_vars warning unknown file

Bug #64325 [Com]: Issue in automatic $_POST array handling

[PHP-BUG] Bug #64340 [NEW]: sockets tests failed

Bug #64340 [PATCH]: sockets tests failed

Req #49526 [Com]: C# style property get/set syntax

Bug #64340 [Com]: sockets tests failed

Bug #61025 [Com]: __invoke() visibility not honored

Req #64484 [Com]: [feature request] second auto_prepend_file

Bug #65291 [PATCH]: get_defined_constants() causes PHP to crash in a very limited case.

Bug #65291 [Com]: get_defined_constants() causes PHP to crash in a very limited case.

Bug #48795 [Com]: Building intl 64-bit fails on OS X

Bug #52909 [Com]: ReflectionMethod::getParameters() return incorrect number of arguments

Req #40457 [Com]: ReflectionProperty lacks method getStartLine() / getEndLine()

Req #53573 [Com]: Invisible "static" property of Closure

Bug #62852 [Com]: Unserialize Invalid Date causes crash

Bug #62852 [PATCH]: Unserialize Invalid Date causes crash

Bug #62852 [Com]: Unserialize Invalid Date causes crash

Bug #62852 [Com]: Unserialize Invalid Date causes crash

Bug #62952 [Com]: Methods from ServerClient cannot be used with ReflectionMethod

Bug #63104 [Com]: php fail to build with --enable-intl

[PHP-BUG] Req #63188 [NEW]: Display class name when debugging with gdb macro zbacktrace

Req #63188 [Com]: Display class name when debugging with gdb macro zbacktrace

Bug #63248 [Com]: ext\fileinfo\tests\bug61964.phpt fails

[PHP-BUG] Bug #63428 [NEW]: The behavior of execute() changed

Bug #64235 [Com]: Insteadof not work for class method in 5.4.11

Bug #64235 [Com]: Insteadof not work for class method in 5.4.11

Bug #36759 [Com]: Objects destructors are invoked in wrong order when script is finished

Bug #36759 [Com]: Objects destructors are invoked in wrong order when script is finished

29 matches

Site Navigation

Mail list logo

Footer information