On Thu, Feb 19, 2009 at 3:14 PM, Ian Eure wrote:
> On Feb 18, 2009, at 6:52 PM, Moriyoshi Koizumi wrote:
>
>> On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski
>> wrote:
>>>
>>> Moriyoshi Koizumi wrote:
As I said earlier, the function is never supposed to be used with
objects. There
>
>
>
> allow_call_time_pass_reference = Off (Issue Warnings)
>
+1
Regards
Marco
+1 Off (Issue warnings)
On Feb 18, 2009, at 11:34 PM, Eric Stewart wrote:
We seem to have a split opinion on what the production INI value for
allow_call_time_pass_reference should be.
As I understand it, this does not enable or disable the ability to
pass
references at call time. It only en
On Feb 18, 2009, at 6:52 PM, Moriyoshi Koizumi wrote:
On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski > wrote:
Moriyoshi Koizumi wrote:
As I said earlier, the function is never supposed to be used with
objects. Therefore, we cannot declare it to be broken, and any
change
to the behavior an
Edward Z. Yang wrote:
> The previous patch is wrong (it doesn't handle the flush();flush(); case
> well). Here's a better one, although it's 304 specific:
Bump?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
We seem to have a split opinion on what the production INI value for
allow_call_time_pass_reference should be.
As I understand it, this does not enable or disable the ability to pass
references at call time. It only enables or disables PHP's warnings about
this behavior.
I currently have it set t
Christopher,
I looked into the addition of the use of variables in the INI files and I
wasn't able to find much documentation on it. Also, I haven't been able to
play with them and see exactly how they work. For now I don't feel confident
in adding my own comments about it. If you want to write up
On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski wrote:
> Moriyoshi Koizumi wrote:
>>
>> As I said earlier, the function is never supposed to be used with
>> objects. Therefore, we cannot declare it to be broken, and any change
>> to the behavior anyway leads to a huge BC break. I got a report tha
Hello Nathan,
Wednesday, February 18, 2009, 3:31:56 PM, you wrote:
> On Wed, Feb 18, 2009 at 6:16 AM, Johannes Schlüter wrote:
>> But I don't think that a new limitation is any better: Tomorrow we have
>> to change it again as somebody has a reason to use 5 parameters, so if
>> it is changed it
Anyone? Bueller?
Andrei Zmievski wrote:
It seems that our PHP_ADD_EXTENSION_DEP() macro from acinclude.m4 does
not actually do any linking against the dependent extension despite the
comment in it:
dnl Some systems require that we link $2 to $1 when building
The consequence of this is that
Yes, those should be fixed too, but it's more difficult to do because they accept varargs,
so not clear where the flag should go.
-Andrei
Moriyoshi Koizumi wrote:
In addition, we should look at similar comparison-involved array
functions such as array_intersect, array_diff and so on, otherwise
Moriyoshi Koizumi wrote:
As I said earlier, the function is never supposed to be used with
objects. Therefore, we cannot declare it to be broken, and any change
to the behavior anyway leads to a huge BC break. I got a report that
claims the reporter's real-world application behaves strangely with
On Wed, Feb 18, 2009 at 6:16 AM, Johannes Schlüter wrote:
> But I don't think that a new limitation is any better: Tomorrow we have
> to change it again as somebody has a reason to use 5 parameters, so if
> it is changed it should be changed to take any number of arguments and
> no fixed limit..
Marcus Boerger wrote:
Hello shire,
Thursday, February 12, 2009, 8:02:06 PM, you wrote:
Lukas Kahwe Smith wrote:
The following remain open and it does not seem someone is actively
working in it:
- PHP_5_3 missed merge from PHP_5_2 for write_func callback
Seeing as I have an interest in thi
To summarize what were the problems:
1. casting a float value that is unrepresentable in a target type is
undefined according to C spec.
2. any constant values that are unrepresentable in the standard
integer type are automagically represented as double values in PHP.
i.e. 0xc000 will result i
On Wed, Feb 18, 2009 at 6:16 AM, Johannes Schlüter wrote:
> But I don't think that a new limitation is any better: Tomorrow we have
> to change it again as somebody has a reason to use 5 parameters, so if
> it is changed it should be changed to take any number of arguments and
> no fixed limit..
Hi Johannes,
It's not a bug. Just increment opline before return
ZEND_USER_OPCODE_CONTINUE.
execute_data->opline++;
The user opcode can have additionl OP_DATA arguments or perform JMP, so
it can't set next opline automatic.
Thanks. Dmitry.
Johannes Schlüter wrote:
Hi,
while implementing
Hi Zoe, all,
- Original Message -
From: "zoe"
Sent: Wednesday, February 18, 2009
> Moriyoshi Koizumi wrote:
> > Please don't even think of backporting. This will definitely break a
> > lot of things, and this kind of thing must not be done in a minor
> > release.
> >
> >
> --snip--
>
> >>
On Wed, 2009-02-18 at 11:34 +0300, Antony Dovgal wrote:
> > recently, working on an extension, i wanted to call a method w/ 3 params,
> > and as you know, zend_call_method only supports 2 parameters at most. i
> > came across this thread in the archives,
[...]
> What happened to call_user_function
Moriyoshi Koizumi wrote:
Please don't even think of backporting. This will definitely break a
lot of things, and this kind of thing must not be done in a minor
release.
--snip--
I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was
changed by the fix for bug #42868, right?
I
Hi Eric.
On 17.02.2009 8:02 Uhr, Eric Stewart wrote:
extension_dir = "./"
Should be commented out as has been pointed out already by Johannes
Schlüter.
enable_dl = On
enable_dl should be off(). Well, that has been said a few time already... :)
By now I also think that allow_call_time_p
On 18.02.2009 07:08, Nathan Nobbe wrote:
> hi,
>
> recently, working on an extension, i wanted to call a method w/ 3 params,
> and as you know, zend_call_method only supports 2 parameters at most. i
> came across this thread in the archives,
>
> http://marc.info/?l=php-internals&m=12017969031041
22 matches
Mail list logo
