With the recent discussion on E_STRICT and the waste of cpu cycles ...
Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT?
What is unstrict about this?
Why is important to use time() instead?
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
With the recent discussion on
E_STRICTand the waste of cpu cycles ...Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT?
What is unstrict about this?
Why is important to use
time()instead?
It's quicker.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
With the recent discussion on
E_STRICTand the waste of cpu cycles ...Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT?
What is unstrict about this?
Why is important to use
time()instead?It's quicker.
as I just said on IRC:
i think an e_strict in that place is wrong .. for example the parameters
could have been user supplied and you simply check that the parameters
are integers
if e_strict is our way of telling users about back practices, we should
really have a consensus on this list about what constitutes a bad practice.
regards,
Lukas
Derick Rethans wrote:
With the recent discussion on
E_STRICTand the waste of cpu
cycles ...Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT?
What is unstrict about this?
Why is important to use
time()instead?
It's quicker.as I just said on IRC:
i think an e_strict in that place is wrong .. for example the
parameters could have been user supplied and you simply check that
the parameters are integers
That is a weak argument, validation is not just "is the data type
correct or not" it should also perform content checks. Not
understanding of this basic practice is probably why there are so
many insecure PHP applications out-there.
if e_strict is our way of telling users about back practices, we
should really have a consensus on this list about what constitutes
a bad practice.
You are working under the assumption that mktime(0) and alike will
continue working in future versions, that may not end up being the case.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
Derick Rethans wrote:
With the recent discussion on
E_STRICTand the waste of cpu cycles ...Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT?
What is unstrict about this?
Why is important to use
time()instead?
It's quicker.as I just said on IRC:
i think an e_strict in that place is wrong .. for example the
parameters could have been user supplied and you simply check that the
parameters are integersThat is a weak argument, validation is not just "is the data type
correct or not" it should also perform content checks. Not understanding
of this basic practice is probably why there are so many insecure PHP
applications out-there.
Yes, but E_STRICT is not an argument validation error level. Throwing
an E_STRICT here is quite wrong unless we have completely redefined
E_STRICT to mean just about any sort of error. mktime($a) is perfectly
fine at the language level and E_STRICT is supposed to be language-level
errors not something that is thrown based on the value of $a.
-Rasmus
Yes, but
E_STRICTis not an argument validation error level.
Throwing anE_STRICThere is quite wrong unless we have completely
redefinedE_STRICTto mean just about any sort of error. mktime
($a) is perfectly fine at the language level andE_STRICTis
supposed to be language-level errors not something that is thrown
based on the value of $a.
As Pierre had correctly identified the E_STRICT currently is only
raised in 2 instance mktime() <-- no args or when the deprecated dst
parameter is being used. While I agree that E_STRICT maybe misused
there, it is only the case if the decision is to maintain the mktime
() == time() functionality.
Ilia Alshanetsky
Yes, but
E_STRICTis not an argument validation error level. Throwing an
E_STRICThere is quite wrong unless we have completely redefinedE_STRICTto
mean just about any sort of error. mktime($a) is perfectly fine at the
language level andE_STRICTis supposed to be language-level errors not
something that is thrown based on the value of $a.As Pierre had correctly identified the
E_STRICTcurrently is only raised in 2
instancemktime()<-- no args or when the deprecated dst parameter is being
used. While I agree thatE_STRICTmaybe misused there, it is only the case if
the decision is to maintain themktime()==time()functionality.
And I'd be happy to change both to E_DEPRECATED when we get that error
level.
regards,
Derick
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced to an undesired code behavior.
With the recent discussion on
E_STRICTand the waste of cpu cycles ...Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT?
What is unstrict about this?
Why is important to use
time()instead?--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?
c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"--
Ilia Alshanetsky
Hello,
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced to an undesired code behavior.
Which is? mktime(0) is just like mktime(24); if it is not the case,
there is a bug (it is the case). But I suppose you mean mktime(0,0,0,
0,0,0);?
However and for the clarity/sanitiy of this discussion mktime(0,0,0,
0,0,0) does not raise any error, mktime(); does.
To solve the only argument in favour of this error message, Derick
should simply remove the notice and add these three little line before
the arguments parsing:
if (ZEND_NUM_ARGS() == 0) {
RETURN_LONG((long)time(NULL));
}
the slow down is then only an extra C function call. It is an easy
solution for possibly annoying change.
--Pierre
Hello,
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced to an undesired code behavior.Which is? mktime(0) is just like mktime(24); if it is not the case,
there is a bug (it is the case). But I suppose you mean mktime(0,0,0,
0,0,0);?However and for the clarity/sanitiy of this discussion mktime(0,0,0,
0,0,0) does not raise any error,mktime(); does.To solve the only argument in favour of this error message, Derick
should simply remove the notice and add these three little line before
the arguments parsing:if (ZEND_NUM_ARGS() == 0) { RETURN_LONG((long)time(NULL)); }
To be exact:
if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); }
as gmmktime uses php_mktime as well, but in GMT mode.
Pierre wrote:
Hello,
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced to an undesired code behavior.Which is? mktime(0) is just like mktime(24); if it is not the case,
there is a bug (it is the case). But I suppose you mean mktime(0,0,0,
0,0,0);?However and for the clarity/sanitiy of this discussion mktime(0,0,0,
0,0,0) does not raise any error,mktime(); does.To solve the only argument in favour of this error message, Derick
should simply remove the notice and add these three little line before
the arguments parsing:if (ZEND_NUM_ARGS() == 0) { RETURN_LONG((long)time(NULL)); }To be exact:
if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); }
as gmmktime uses php_mktime as well, but in GMT mode.
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.
regards,
Lukas
Pierre wrote:
Hello,
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced to an undesired code behavior.Which is? mktime(0) is just like mktime(24); if it is not the case,
there is a bug (it is the case). But I suppose you mean mktime(0,0,0,
0,0,0);?However and for the clarity/sanitiy of this discussion mktime(0,0,0,
0,0,0) does not raise any error,mktime(); does.To solve the only argument in favour of this error message, Derick
should simply remove the notice and add these three little line before
the arguments parsing:if (ZEND_NUM_ARGS() == 0) { RETURN_LONG((long)time(NULL)); }To be exact:
if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); }
as gmmktime uses php_mktime as well, but in GMT mode.
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.
There is no BC break:
derick@kossu:~$ php-5.2dev -derror_reporting=16383 -r 'echo mktime(), "\n";'
Strict standards: mktime(): You should be using the time() function
instead in Command line code on line 1
1161590781
derick@kossu:~$ php-4.4dev -derror_reporting=16383 -r 'echo mktime(), "\n";'
1161590801
regards,
Derick
Derick Rethans wrote:
Pierre wrote:
Hello,
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced to an undesired code behavior.
Which is? mktime(0) is just like mktime(24); if it is not the case,
there is a bug (it is the case). But I suppose you mean mktime(0,0,0,
0,0,0);?However and for the clarity/sanitiy of this discussion mktime(0,0,0,
0,0,0) does not raise any error,mktime(); does.To solve the only argument in favour of this error message, Derick
should simply remove the notice and add these three little line before
the arguments parsing:if (ZEND_NUM_ARGS() == 0) { RETURN_LONG((long)time(NULL)); }To be exact:
if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); }
as gmmktime uses php_mktime as well, but in GMT mode.
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which
is the point of the message, right?
regards,
Lukas
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which is the
point of the message, right?
Yeah, but there is no point in calling mktime() without arguments as you
can use time() doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's an E_STRICT message for ****s sake.
regards,
Derick
Hello,
Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.
There is no point to keep this message, the fix is easy and does not
bring any additional troubles. A lot of applications use mktime()
without arguements, I did not read or hear any valid reason to do not
fix this issue.
--Pierre
Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.There is no point to keep this message, the fix is easy and does not
bring any additional troubles. A lot of applications usemktime()
without arguements, I did not read or hear any valid reason to do not
fix this issue.
Stop whining about every code I contribute. It's staying.
Derick
Hello,
Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.There is no point to keep this message, the fix is easy and does not
bring any additional troubles. A lot of applications usemktime()
without arguements, I did not read or hear any valid reason to do not
fix this issue.Stop whining about every code I contribute. It's staying.
Excuse me, can you explain what you mean?
I explain you how the code you wrote works and how easy it is to fix
it. A simple search clearly shows that a lot of applications use these
two functions without arguments and you keep ignore this fact.
Anyway, Derick's law applies again here. I really don't care, I only
tried to provide a valid explanation and solution to a valid problem.
Things that you, maintainer of this extension, is not able to provide.
--Pierre
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which is the
point of the message, right?Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.
In a simple test, 100000 calls to time() took 0.055 seconds and
mktime() took 3.2 seconds.
Nearly 60 times faster to use time().
Didn't realise that.
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hello,
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which is the
point of the message, right?Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.In a simple test, 100000 calls to
time()took 0.055 seconds and
mktime()took 3.2 seconds.Nearly 60 times faster to use
time().Didn't realise that.
If you read the other replies to your initial question (which was
wrong :), you will realize another thing, this is easily fixable with
minimum effort and impact:
http://pecl.php.net/~pierre/remove_mktime_strict.txt
No visible speed difference
.
--Pierre
Hello,
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which is the
point of the message, right?Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.In a simple test, 100000 calls to
time()took 0.055 seconds and
mktime()took 3.2 seconds.Nearly 60 times faster to use
time().Didn't realise that.
If you read the other replies to your initial question (which was
wrong :), you will realize another thing, this is easily fixable with
minimum effort and impact:http://pecl.php.net/~pierre/remove_mktime_strict.txt
No visible speed difference
.
--Pierre
Yes. I was wrong. Sorry. And a perfect fix. Now mktime() is an alias
for time(), except when additional parameters are supplied.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
If you read the other replies to your initial question (which was
wrong :), you will realize another thing, this is easily fixable with
minimum effort and impact:http://pecl.php.net/~pierre/remove_mktime_strict.txt
No visible speed difference
I see no reason to make mktime() an alias of time(), you are
basically advocating misuse of functions. Yes there are over 2,000
results on google showing people calling mktime(), but I bet there
are even more register_globals users and yet we've all decided to
remove it in PHP6.
Ilia Alshanetsky
Hello,
If you read the other replies to your initial question (which was
wrong :), you will realize another thing, this is easily fixable with
minimum effort and impact:http://pecl.php.net/~pierre/remove_mktime_strict.txt
No visible speed difference
I see no reason to make
mktime()an alias oftime(), you are
basically advocating misuse of functions. Yes there are over 2,000
results on google showing people callingmktime(), but I bet there
are even more register_globals users and yet we've all decided to
remove it in PHP6.
Ilia, it is not about making an alias. It is about restoring a widely
use behavior in mktime and about making gmktime useable. This change
is nothing but a unilateral break (even in E_STRICT).
Unilateral break? lol...
Actually it is no break at all, take PHP4 code move it to PHP and you
won't even see the warning because E_STRICT is not even shown by
default.
Hello,
If you read the other replies to your initial question (which was
wrong :), you will realize another thing, this is easily fixable
with
minimum effort and impact:http://pecl.php.net/~pierre/remove_mktime_strict.txt
No visible speed difference
I see no reason to make
mktime()an alias oftime(), you are
basically advocating misuse of functions. Yes there are over 2,000
results on google showing people callingmktime(), but I bet there
are even more register_globals users and yet we've all decided to
remove it in PHP6.Ilia, it is not about making an alias. It is about restoring a widely
use behavior in mktime and about making gmktime useable. This change
is nothing but a unilateral break (even in E_STRICT).--
Ilia Alshanetsky
Ilia Alshanetsky wrote:
Actually it is no break at all, take PHP4 code move it to PHP and you
won't even see the warning becauseE_STRICTis not even shown by default.
haha
regards,
Lukas
Hello,
Unilateral break? lol...
Actually it is no break at all, take PHP4 code move it to PHP and you
won't even see the warning becauseE_STRICTis not even shown by
default.
Anyway, I made my point, my patch prooves that this change is
completelly useless and only adds more annoyances to the e_strict
stack. If the documented behaviors can be ignored from now on, I don't
care, as long as it applies to anyone, any code or functions.
--Pierre
Hello,
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which is the
point of the message, right?Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.
How can I have "gmmktime();" (which also uses php_mktime) with time()?
--PIerre
Hello,
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which is
the
point of the message, right?Yeah, but there is no point in calling
mktime()without arguments as you
can usetime()doing the same. It's just a friendly hint that you're
wasting CPU cycles. It's anE_STRICTmessage for ****s sake.How can I have "gmmktime();" (which also uses php_mktime) with
time()?
gmmktime() without parameters is broken in PHP 4 anyway. If you don't
give it arguments than it should default to the current date
and hour (in GMT for gmmktime() and in localtime for
mktime()). In both places this should result in the same timestamp,
which gmmktime() doesn't even do on PHP 4:
derick@kossu:~$ php-4.4dev -r 'echo mktime(), "\n", gmmktime(), "\n", time(), "\n";'
1161625133
1161632333
1161625133
(it substracts an hour if you are in DST without any valid reason).
PHP 5.1+ handles this correctly:
derick@kossu:~$ php -r 'echo mktime(), "\n", gmmktime(), "\n", time(), "\n";'
1161625256
1161625256
1161625256
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello,
gmmktime()without parameters is broken in PHP 4 anyway. If you don't
give it arguments than it should default to the current date
and hour (in GMT forgmmktime()and in localtime for
mktime()). In both places this should result in the same timestamp,
whichgmmktime()doesn't even do on PHP 4:
Our point is to do not raise any warning in these two functions when
they are called without arguments. Misunderstanding of the GMT idea by
the previous implementation is another topic.
I do not understand why it is a problem to add three lines to
php_mktime and forget about it rather than adding more pain to the
e_strict stack.
You like to use only time()? fine, but we still have no way to use
"gmmktime();" without warning and we are forced to change our mktime()
calls, for no reason.
--Pierre
Hello Pierre,
shouldn't we use E_NOTICE here? obviously there is something wrongwith
those calls and other functions that check their input typically raise them
as E_NOTICE or E_WARNING. In this case I personally would prefer E_NOTICE
and think E_STRICT is wrong. If we had E_DEPRECATED we could argue. When
really dropping supportfor these values/calls they would lead to an E_ERROR
in later versions so E_DEPRECATED now would be correct. Since we don't have
E_DEPRECATEDright now and E_STRICT is used for deprecated stuff as well it
makes sense. But i alsoagree with Rasmus that this is a domain error, thus
E_NOTICE seems to be the right way after all.
All in all and that is the main reason i am replying is that at least to me
this is another proof that we need E_DEPRECATED rather now (as in 5.2.0)
than later.
best regards
marcus
p.s.: I am neither disagreeing nor agreeing with you in particular here
Pierre, your mail is just the last one i read in this thread...
Monday, October 23, 2006, 8:00:13 PM, you wrote:
Hello,
gmmktime()without parameters is broken in PHP 4 anyway. If you don't
give it arguments than it should default to the current date
and hour (in GMT forgmmktime()and in localtime for
mktime()). In both places this should result in the same timestamp,
whichgmmktime()doesn't even do on PHP 4:
Our point is to do not raise any warning in these two functions when
they are called without arguments. Misunderstanding of the GMT idea by
the previous implementation is another topic.
I do not understand why it is a problem to add three lines to
php_mktime and forget about it rather than adding more pain to the
e_strict stack.
You like to use only
time()? fine, but we still have no way to use
"gmmktime();" without warning and we are forced to change ourmktime()
calls, for no reason.
--Pierre
Best regards,
Marcus
Hello,
Hello Pierre,
shouldn't we use
E_NOTICEhere? obviously there is something wrongwith
those calls
That's where our opinions differ. There is nothing wrong with these
calls and it is a documented behavior. If you take a look at my patch,
you will notice how easy it is to make php_mktime as fast as time()
when no argument are given. Minimum effort for zero impact in
userland. But no, it's too easy.
--Pierre