php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66251 Constants get statically bound at compile time when Optimized
Submitted: 2013-12-10 01:48 UTC Modified: 2013-12-10 11:45 UTC
From: Terry at ellisons dot org dot uk Assigned: dmitry (profile)
Status: Closed Package: opcache
PHP Version: master-Git-2013-12-09 (Git) OS: N/A
Private report: No CVE-ID: None
 [2013-12-10 01:48 UTC] Terry at ellisons dot org dot uk
Description:
------------
The B/C behaviour is to bind constants at execution of the DEFINE_CONSTANT opcode.  The 5.6 optimizer now attempts to evaluate them at compile time, which changes the execution behaviour.

Test script:
---------------
--TEST--
Terry_001   Constants get statically bound at compile time when Optimized
--INI--
opcache.enable=1
opcache.enable_cli=1
opcache.optimization_level=-1
--SKIPIF--
<?php if (!extension_loaded('Zend OPcache') || php_sapi_name() != "cli") die("skip CLI only"); ?>
--FILE--
<?php
printf ("A=%s\n", getA());
const A="hello";
function getA() {return A;}
--CLEAN--	
--EXPECTF--
Notice: Use of undefined constant A - assumed 'A' in %son line %d
A=A


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-12-10 09:11 UTC] laruence@php.net
-Assigned To: +Assigned To: dmitry
 [2013-12-10 09:11 UTC] laruence@php.net
the previous is a wrong usage... so I think the current opt is okey...

thanks
 [2013-12-10 10:15 UTC] Terry at ellisons dot org dot uk
Xinchen, I've tabled the simplest test case which shows this bug.  It shows that 5.6 executor instead of evaluating constants at runtime when the DECLARE_CONSTANT instruction is executed, you are now evaluating the constant during the compile when the const statement is parsed.  

Whether or not you feel that this is the wrong usage it is how 5.3.x, 5.4.x and 5.5.x do it.  5.6 doesn't.  This is a fundamental B/C break.  It also breaks opcachability.

Where it will hit real apps is where this practice is embedded in a compiled script, because the next execution might have defined the constant differently prior to the compile, for example USERS_LANGUAGE.

I can add more test scripts which look more "real world", but this is the simplest one that I could find that shows the bug.
 [2013-12-10 11:45 UTC] dmitry@php.net
Yeah, it's a problem because script may behave differently with opcache enabled.

We may limit constants evaluation with more strict guards (e.g. if there is a function call before constant decalarations) and/or introduce an opcache ini option that may disable/enable this optimization.
 [2013-12-10 13:08 UTC] dmitry@php.net
Automatic comment on behalf of dmitry@zend.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=73f13f439b3e10cca9b17e7f15c06e7fd11eb6c9
Log: Fixed bug #66251 (Constants get statically bound at compile time when Optimized)
 [2013-12-10 13:08 UTC] dmitry@php.net
-Status: Assigned +Status: Closed
 [2013-12-10 18:47 UTC] ab@php.net
Automatic comment on behalf of dmitry@zend.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=73f13f439b3e10cca9b17e7f15c06e7fd11eb6c9
Log: Fixed bug #66251 (Constants get statically bound at compile time when Optimized)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 14:01:30 2024 UTC