php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34551 Unadvertised BC break
Submitted: 2005-09-19 18:15 UTC Modified: 2005-09-19 19:14 UTC
From: truth at proposaltech dot com Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 4.4.0 OS: SuSE w/ rebuilt php & deps
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: truth at proposaltech dot com
New email:
PHP Version: OS:

 

 [2005-09-19 18:15 UTC] truth at proposaltech dot com
Description:
------------
Based on the discussion on internals that led to the 
creation of php 4.4 (and based on the release notes
for php 4.4), I would expect the only difference in
running the following code under 4.3 and 4.4 to be the
generation of a notice under 4.4.  The code is bad,
but it does not rely on corrupting memory.
(BTW, this actually doesn't affect me personally because 
I immediately cleaned up our company's code for every
4.4 notice.  I'm just helping isolate the BC break
that frustrated a recent internals poster.  Unless
they are relying on memory corruption, users should be
able to hide the notices and get the same behavior
with 4.4 as 4.3.  (There were posts from Zeev among
others supporting this position.))

I hope this is easy to fix.  The concept is easy.
Whenever the code attempts to set a variable by
reference, the variable should be unset as a first
step.  In the example, $y should be disconnected
from $x because of the "$y =& ...".  Yes, the reference
shouldn't actually work, but that doesn't change the
fact that the code clearly indicates that the connection
between $y and $x should be broken.  If I sound
defensive, it's because Derick has already posted on
internals that the new behavior is "correct".  Please
check with other engine gurus before jumping to any
conclusions of bogusness.  I think a fix to this BC
break will save many hours for many, many php 
developers.  (The example is silly, but you
can get subtle cases of that problem in loops that
are a nightmare to find.)

Thanks!
- Todd

Reproduce code:
---------------
<?php
function f() { return 3; }
$x = 5;
$y =& $x;
$y =& f();
var_dump($x);
?>


Expected result:
----------------
$x should end up 5 because the "$y=&..." should disconnect
$y from $x even though the new connection can't be made.

Actual result:
--------------
Under 4.3, $x ends up 5, but under 4.4, $x ends up 3.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-19 18:29 UTC] iliaa@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

Release announcement is pretty clear about this, this is why the release is 4.4.0 and not 4.3.12
 [2005-09-19 19:14 UTC] truth at proposaltech dot com
According to http://www.php.net/release_4_4_0.php...

It states, "The increased middle digit was required because the fix that corrected the problem with references changed PHP's internal API, breaking binary compatibility with the PHP 4.3.* series."  Please note the middle digit change regarded an _internal_ API, not an API visible to the user.

It also states, "... will now throw an E_NOTICE when references are incorrectly used in the script. This is intended to alert developers to minor errors in their approach, and does not affect the script's performance in any other way."  Not disconnecting a variable from previous reference assignments when using an "=&" does indeed affect a script's performance in a way beyond throwing notices.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Wed Jul 16 21:01:33 2025 UTC