Everything

php

extract(EXTR_REFS) and pass-by-reference

php.internals

Moriyoshi Koizumi

21 years ago

Hi there,

I'm now looking into the three extract() bugs related to
each other, namely bug #25708, bug #29493 and bug #31213.

It turned out after all that these problems are caused
by a inevitable zval separation on sending arguments
to the function and there seems to be no feasible workaround
for now. I got stuck with a couple of mentioned ways that fix
the problem just partly, not entirely.

a. Specify first_arg_force_ref to PHP_FE(extract).
This will cause the engine to yell a
only-variables-can-be-passed-by-reference!
when you directly pass a scalar (temporary variable) to it.

b. Turn on allow_call_time_pass_by_reference.
This is anyway deprecated, but looks like the best way around from the
my point of view.

Any suggestions will be appreciated.

Moriyoshi

Marcus Börger

21 years ago

Hello Moriyoshi, Hello Andi

Sunday, January 2, 2005, 7:35:05 AM, you wrote:

> Hi there,

> I'm now looking into the three extract() bugs related to
> each other, namely bug #25708, bug #29493 and bug #31213.

> It turned out after all that these problems are caused
> by a inevitable zval separation on sending arguments
> to the function and there seems to be no feasible workaround
> for now. I got stuck with a couple of mentioned ways that fix
> the problem just partly, not entirely.

> a. Specify first_arg_force_ref to PHP_FE(extract).
>    This will cause the engine to yell a
> only-variables-can-be-passed-by-reference!
>    when you directly pass a scalar (temporary variable) to it.

> b. Turn on allow_call_time_pass_by_reference.
>    This is anyway deprecated, but looks like the best way around from the
>    my point of view.

> Any suggestions will be appreciated.

> Moriyoshi

while i tried to improve performance of the array functions i developed a
new pass type - pass as const which doesn't touch the passed variable at
all and is compatible with temp vars, too. Maybe your problem here is a
reason to really implement that. Andi what do you think?

--
Best regards,
Marcus                            mailto:helly@php.net

Moriyoshi Koizumi

21 years ago

On 2005/01/02, at 21:23, Marcus Boerger wrote:

> while i tried to improve performance of the array functions i
> developed a
> new pass type - pass as const which doesn't touch the passed variable
> at
> all and is compatible with temp vars, too. Maybe your problem here is a
> reason to really implement that. Andi what do you think?

I think the feature you are proposing will likely be necessary either
way.
It can also make the output of debug_zval_dump() reliable as
implicit separation of zval instances results with bogus reference
counts.

Moriyoshi

Andi Gutmans

21 years ago

At 06:26 PM 1/4/2005 +0900, Moriyoshi Koizumi wrote:

>On 2005/01/02, at 21:23, Marcus Boerger wrote:
>
>>while i tried to improve performance of the array functions i developed a
>>new pass type - pass as const which doesn't touch the passed variable at
>>all and is compatible with temp vars, too. Maybe your problem here is a
>>reason to really implement that. Andi what do you think?
>
>I think the feature you are proposing will likely be necessary either way.
>It can also make the output of debug_zval_dump() reliable as
>implicit separation of zval instances results with bogus reference
>counts.

There were some good reasons not to implement this change and it definitely
just complicated things without giving a real gain.
Making debug_zval_dump() reliable is not a good reason.

Andi

Moriyoshi Koizumi

21 years ago

On 2005/01/05, at 1:31, Andi Gutmans wrote:

> At 06:26 PM 1/4/2005 +0900, Moriyoshi Koizumi wrote:
>
>> On 2005/01/02, at 21:23, Marcus Boerger wrote:
>>
>>> while i tried to improve performance of the array functions i
>>> developed a
>>> new pass type - pass as const which doesn't touch the passed
>>> variable at
>>> all and is compatible with temp vars, too. Maybe your problem here
>>> is a
>>> reason to really implement that. Andi what do you think?
>>
>> I think the feature you are proposing will likely be necessary either
>> way.
>> It can also make the output of debug_zval_dump() reliable as
>> implicit separation of zval instances results with bogus reference
>> counts.
>
> There were some good reasons not to implement this change and it
> definitely just complicated things without giving a real gain.
> Making debug_zval_dump() reliable is not a good reason.

Well, then we'd better off getting rid of extract(EXTR_REFS), which
would
(and will) never work as advertised.

Yet I'm still wondering how complicate it will be if we introduce
a new argument modifier with which non-variable scalars are just
passed to the function as usual, and variables are passed the
way as if it was forcefully referenced.

Moriyoshi