Solved

Changing INI settings has no effect

Posted on 2006-07-20
19
363 Views
Last Modified: 2008-02-01
Hi fellas,

I just tried the following code with PHP 5.0.4 installed:

<?php
error_reporting(E_STRICT);
class myc {
    var $ttt;  // var is deprecated in PHP 5
    function test() {
    }
}
$x = new myc();
?>

but it does not show up the "deprecated" warning message in the browser as well as in the console (> php myfile.php).

But if I run this code in the console like:

> php -d error_reporting=4095 myfile.php

It does show up: "Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /srv/www/htdocs/entw/ldbkutty/myinfo.php on line 4"

Any ideas why the error_reporting(E_STRICT) has no effect here?
0
Comment
Question by:ldbkutty
  • 12
  • 4
  • 2
  • +1
19 Comments
 
LVL 40

Expert Comment

by:RQuadling
ID: 17146209
<?php
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 1);

class myc_class
      {
      var $ttt;
      public $pub;
      protected $prot;
      private $priv;
      
      public function __construct()
            {
            $this->ttt = 2;
            }
      public function test()
            {
            echo $this->ttt;
            }
      }

echo 1;
$x = new myc_class();
$x->test();
echo 3;
var_dump($x);
?>

I'm on PHP 5.2.0-dev (cli) (built: Jul 12 2006 12:20:25)

and my output is ...

123object(myc_class)#1 (4) {
  ["ttt"]=>
  int(2)
  ["pub"]=>
  NULL
  ["prot:protected"]=>
  NULL
  ["priv:private"]=>
  NULL
}

In other words, var is now assumed to be public.

0
 
LVL 29

Expert Comment

by:TeRReF
ID: 17146210
Add this under error_reporting and see if tht works...
 ini_set('display_errors', 'On');
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17146236
I suspect your CLI version of PHP is different to your webservers version.

At the cli ...

php -v

and then see what version <?php phpinfo(); ?> reveals via your browser.
0
 
LVL 40

Accepted Solution

by:
RQuadling earned 125 total points
ID: 17146394
0
 
LVL 32

Author Comment

by:ldbkutty
ID: 17146400
I do have 'display_errors' set to ON.

>> In other words, var is now assumed to be public.
Thats right, but  according to the "Note:" here: http://de3.php.net/manual/en/language.oop5.visibility.php#AEN5817 I should get the deprecated warning message if I have E_STRICT enabled, right?

>> I suspect your CLI version of PHP is different to your webservers version.
Its the same!

btw, how are you doing RQuadling ?
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17146414
There is no point in setting E_STRICT at run time as E_STRICT is only processed during parsing, before the code is run. E_STRICT must be set in the INI file.
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17146417
I'm doing well.

You?
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17146443
Just tested with PHP 5.2.0-dev (cli) (built: Jul 20 2006 12:20:26)

And it seems E_Strict is now amendable at run time!
0
 
LVL 32

Author Comment

by:ldbkutty
ID: 17146472
I guessed the same, its a BUG !

Thank you. And I am fine too :-)
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Expert Comment

by:TertiumNonDatur
ID: 17152542
This is also strange and might be a problem in the same context:

class c1 {
    function test1() {
    }
}
class c2 {
    function test2() {
        c1::test1();         /* Critical line */
    }
}

Now this call produces a strict message:
c1::test1();
PHP Strict Standards:  Non-static method c1::test1() should not be called statically


However, these calls do not:
$x = new c2();
$x->test2();

I would have expected that the execution of the /* Critical line */
is interpreted as a static function call and should generate a
strict message, but it doesn't.





0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17152565
Declare c1's method test1 as static and the issue is resolved.

<?php

class c1 {
    static function test1() {
    }
}
class c2 {
    function test2() {
        c1::test1();
    }
}

$x = new c2();
$x->test2();
?>
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17152574
With my PHP and this code ...

<?php

class c1 {
    function test1() {
    }
}
class c2 {
    function test2() {
        c1::test1();         /* Critical line */
    }
}

$x = new c2();
$x->test2();
?>

I get ...

Strict Standards: Non-static method c1::test1() should not be called statically, assuming $this from incompatible context in C:\er4.php on line 9


Using PHP 5.2.0-dev (cli) (built: Jul 20 2006 12:20:26)
0
 

Expert Comment

by:TertiumNonDatur
ID: 17153039
OK, I admit, my PHP version is not the newest, latest, hypest:

php5 --version
PHP 5.0.3 (cgi) (built: Mar 22 2005 20:12:51)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies

@RQuadling: Actually, test1() should not be a static function.
So what I need is a strict message if somebody wants to use
this function in a static way (which should not be the case).

However, when this is fixed in newer PHP versions - that's what
I want :-).

Regards
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17153062
If it is being called as a static it has to be allowed a call as static, I think!
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17153069
"Tertium Non Datur" ? Nah. Ask any woman. Yes / No / Maybe. The third state ALWAYS exists and more often than not may be either of the other states simultaneously!
0
 

Expert Comment

by:TertiumNonDatur
ID: 17157013
RQuadling wrote

> If it is being called as a static it has to be allowed a call as static, I think!

Sure, but this is not the point. The class definition might be MY CODE. And the caller might be SOMEONE ELSE who didn't look at the function definition exactly enough. And this other person SHOULD get the strict message, don't you think?

Regards
TertiumNonDatur (I am no woman ;-)
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17157487
If E_STRICT is enabled and you call a method statically and the method is NOT defined as static, then I get the error.

I think this is correct.

As far as documentation is concerned, that is why phpDoc exists. Makes a LOT of this sort of thing REALLY obvious.
0
 

Expert Comment

by:TertiumNonDatur
ID: 17165930
YOU get the error with your PHP version. I DO NOT get the error (with my older PHP version). Got it?
0
 
LVL 40

Expert Comment

by:RQuadling
ID: 17166437
I think the E_STRICT is slightly wonky anyway. All sorts of things come out when they shouldn't and as you see, don't when they should!

0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Suggested Solutions

These days socially coordinated efforts have turned into a critical requirement for enterprises.
Password hashing is better than message digests or encryption, and you should be using it instead of message digests or encryption.  Find out why and how in this article, which supplements the original article on PHP Client Registration, Login, Logo…
The viewer will learn how to look for a specific file type in a local or remote server directory using PHP.
This tutorial will teach you the core code needed to finalize the addition of a watermark to your image. The viewer will use a small PHP class to learn and create a watermark.

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now