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

go to bug id or search bugs for

Bug #44396 class compilation notices refer to wrong line number
Submitted: 2008-03-10 18:00 UTC Modified: 2008-03-10 23:30 UTC
From: frase at cs dot wisc dot edu Assigned:
Status: Not a bug Package: Class/Object related
PHP Version: 5.2.5 OS: Ubuntu 7.10
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: frase at cs dot wisc dot edu
New email:
PHP Version: OS:

 

 [2008-03-10 18:00 UTC] frase at cs dot wisc dot edu 
Description:
------------
If a class definition generates a notice, the line number printed with the notice corresponds to the first line in which the class is instantiated, and NOT the line which truly gives rise to the notice.


Reproduce code:
---------------
class OtherClass {
  // etc...
}
class TestClass {
  static $linkedClass = OtherClass;
  function __construct() {
    echo "I am linked to " . self::$linkedClass;
  }
}
$obj = new TestClass();


Expected result:
----------------
I am linked to OtherClass


Actual result:
--------------
Notice: Use of undefined constant OtherClass - assumed 'OtherClass' in test.php on line 10
I am linked to OtherClass



Line 10 does not contain the phrase 'OtherClass' to begin with, as an undefined constant or otherwise, so the notice is confusing.  The line on which the notice actually arises is line 5, where the class' static member is incorrectly initialized (it should, in fact, have been a string).

Disclaimer: The need to have one class refer to another by name, as in this example, may seem odd but is irrelevant to this bug report (it arose for me because of a more complicated class inheritance need).  I suspect any notice arising during a class' static member initialization will have the same wrong line-number; errors other than E_NOTICE might as well, I haven't taken the time to check exhaustively.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-03-10 18:58 UTC] colder@php.net 
The problem here is that the constant is evaluated just in time, which means it will only be looked for when you instantiate the class. Your example may be reduced to :

class A {
   public $a = FOOBAR;
}
$a = new A; // Error will be triggered at this point.

Currently the line at which the constant is actually used is not tracked.
 [2008-03-10 19:18 UTC] frase at cs dot wisc dot edu 
Thanks for the reply.  That explains /why/ it happens, but it still is not ideal behavior; in a very large class, it could take someone a long, long time to track down the origin of this message, since the line number attached to it is meaningless.

I suppose I'm not expecting a quick patch to fix this, since it is a relatively minor problem and I imagine the constant-reference tracking necessary to solve it would have larger performance implications.  But I thought it worth noting at least, in case some future change to PHP's internals makes it viable to address this.
 [2008-03-10 21:07 UTC] johannes@php.net 
Checking this during compilation would require to lookup the constant during compilation, but we don't enforce the declaration order to allow more flexible code, yes the message is not perfect but that can't be changed without major changes which break PHP's current behviour.
 [2008-03-10 23:30 UTC] frase at cs dot wisc dot edu 
Yes, I understand that, and I agree that performance and constant-definition-order-flexibility are more important than the accuracy of this error message.  As I said, I do not necessarily expect an immediate patch for this.

However, I would still petition that this report is not "bogus", because "bogus" implies that there is no mistake to fix.  But this message is, in fact, incorrect, since the undefined constant does not occur on the line indicated -- the fact that it may not be worth fixing at this time does not change the validity of that observation.

A "will not fix" or "fix deferred indefinitely" or some such designation seems more appropriate to me.  That way, if some future change to PHP's internals makes this easier to solve, this report will remain as a reminder.
 [2010-03-12 20:12 UTC] sebastian at sebsoft dot nl 
Would it be possible to add a check or enforcing a check for this?
I imagine you don't want something like this in a production environment, but it might be good to create some kind of ini setting for this.
It might help with debugging.
I do agree this might be 'won't fix' for production environments, but for development, I really would like to see a solution for this issue.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Jul 04 20:01:35 2025 UTC