php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: Terry at ellisons dot org dot uk
New email:
PHP Version: OS:

 

 [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

Pull Requests

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-2025 The PHP Group
All rights reserved. 		Last updated: Wed Nov 05 07:00:01 2025 UTC