Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] date() behaviour changed in 5.1? [RSS Feed]

#1 Nov. 15, 2005 16:32:15

Sean C.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


I discussed this with Rasmus and Derick, yesterday, but I don't think we
came to a conclusion..

Is this a bug, or intended behaviour?

:~$ /opt/src/php-5.0.4/sapi/cli/php -r 'echo date("r",
"1132003418 ") ."\n";'
Mon, 14 Nov 2005 16:23:38 -0500
:~$ /opt/src/php5-200511131530/sapi/cli/php -r 'echo
date("r", "1132003418 ") ."\n";'

Warning: date() expects parameter 2 to be long, string given in Command
line code on line 1

:~$

The conclusion SEEMED to be that it's a bug in the parameter parsing API
(as date() now uses the new API).

I think that the 2nd param should automatically be cast to an int. Yes,
I realize that the documentation says it should be an int, and I'm ok
with that (the extraneous whitespace is my fault). I think it should be
mentioned in the release docs if it won't be fixed, though.

Also, a warning is pretty harsh. A E_NOTICE is more representative of
what's happening. Also, in the E_WARNING scenario above, date() no
longer returns the expected result (based on <=5.0 code).

So: is this a bug? If so, I can send a report -- I just didn't want it
to get bogussed without discussion.

If not -- I really think this should be fixed before 5.1.. I realize
it's very late in the game, though.

Opinions?

S

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 Nov. 15, 2005 17:00:12

Jani T.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)

Nothing to fix here, move along. (and fix your code..)

--Jani


On Tue, 15 Nov 2005, Sean Coates wrote:I discussed this with Rasmus and Derick, yesterday, but I don't think we
came to a conclusion..

Is this a bug, or intended behaviour?

:~$ /opt/src/php-5.0.4/sapi/cli/php -r 'echo date("r",
"1132003418 ") ."\n";'
Mon, 14 Nov 2005 16:23:38 -0500
:~$ /opt/src/php5-200511131530/sapi/cli/php -r 'echo
date("r", "1132003418 ") ."\n";'

Warning: date() expects parameter 2 to be long, string given in Command
line code on line 1

:~$

The conclusion SEEMED to be that it's a bug in the parameter parsing API
(as date() now uses the new API).

I think that the 2nd param should automatically be cast to an int. Yes,
I realize that the documentation says it should be an int, and I'm ok
with that (the extraneous whitespace is my fault). I think it should be
mentioned in the release docs if it won't be fixed, though.

Also, a warning is pretty harsh. A E_NOTICE is more representative of
what's happening. Also, in the E_WARNING scenario above, date() no
longer returns the expected result (based on <=5.0 code).

So: is this a bug? If so, I can send a report -- I just didn't want it
to get bogussed without discussion.

If not -- I really think this should be fixed before 5.1.. I realize
it's very late in the game, though.

Opinions?

S--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Nov. 15, 2005 17:13:38

P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
(Jani Taskinen) wrote:

>
> If you pass bad data to a function, it should not warn you?
> I'd rather have it as a FATAL error. :)
>
> Nothing to fix here, move along. (and fix your code..)

PHP is losely typed, I see nothing wrong to pass an integer as string
there (for example, imagecreate("100", "100"); works).

--Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 Nov. 15, 2005 17:18:33

Rasmus L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


Jani Taskinen wrote:If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)

Nothing to fix here, move along. (and fix your code..)The issue here is we effectively have two different casting mechanisms.One of the things we need to do when moving to PHP 6 is to make sureeverything is using zend_parse_parameters() to handle functionparameters. Most people would assume that a function that wasn't usingzend_parse_parameters() before and was defined to take a long and thuspassed the parameter through convert_to_long() wouldn't change itsbehaviour when moved to zend_parse_parameters() with an "l".That is:

zval **foo;
long lfoo;
zend_get_parameters_ex(1, &foo)
convert_to_long_ex(foo);
lfoo = Z_LVAL_PP(foo);

is not equivalent to:

long foo;
zend_parse_parameters(1, "l", &foo);In order to not change the behaviour of the function moving tozend_parse_parameters() from zend_get_parameters() you have to use a "z"and do the convert_to_long yourself.The reason for this is that is_numeric_string() has a flag calledallow_errors which specifies whether or not it should be strict. Whenyou cast from PHP or use one of the conversion functions internally thisflag is off. When calling zend_parse_parameters it is on.I am not sure what the right answer here is. I can see the argument forbeing strict on parameter types, but at the same time, we willpotentially be breaking a lot of existing code. And at a higher level Idon't like the concept of having two different casting modes.-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Nov. 15, 2005 17:19:35

Sean C.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


Pierre wrote:
> On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
> (Jani Taskinen) wrote:
>
>
>> If you pass bad data to a function, it should not warn you?
>> I'd rather have it as a FATAL error. :)
>>
>> Nothing to fix here, move along. (and fix your code..)
>
>
> PHP is losely typed, I see nothing wrong to pass an integer as string
> there (for example, imagecreate("100", "100"); works).

FWIW, I don't mind forcing an INT here (or an all-numeric string) -- I
know my code was wrong; I admitted this in the first mail.

We need to warn users about it, if we do, though.

I'm only bringing this up because the behaviour _changed_ from 5.0

S

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 Nov. 15, 2005 17:20:08

Rasmus L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


Pierre wrote:On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
(Jani Taskinen) wrote:If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)

Nothing to fix here, move along. (and fix your code..)PHP is losely typed, I see nothing wrong to pass an integer as string
there (for example, imagecreate("100", "100"); works).The question isn't what to do with "100","100" but what to do with"100abc","100abc". Should that still work? The oldzend_get_parameters() following by a convert_to_long() says Yes. Thenewer zend_parse_parameters() says no.-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 Nov. 15, 2005 17:20:45

P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


On Tue, 15 Nov 2005 09:17:20 -0800
(Rasmus Lerdorf) wrote:

> Pierre wrote:
> > On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
> > (Jani Taskinen) wrote:
> >
> >> If you pass bad data to a function, it should not warn you?
> >> I'd rather have it as a FATAL error. :)
> >>
> >> Nothing to fix here, move along. (and fix your code..)
> >
> > PHP is losely typed, I see nothing wrong to pass an integer as
> > string there (for example, imagecreate("100", "100"); works).
>
> The question isn't what to do with "100","100" but what to do with
> "100abc","100abc". Should that still work? The old
> zend_get_parameters() following by a convert_to_long() says Yes. The
> newer zend_parse_parameters() says no.

My answer was to Jani's.

--Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 Nov. 15, 2005 17:26:58

Jani T.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:Pierre wrote:On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
(Jani Taskinen) wrote:If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)

Nothing to fix here, move along. (and fix your code..)PHP is losely typed, I see nothing wrong to pass an integer as string
there (for example, imagecreate("100", "100"); works).The question isn't what to do with "100","100" but what to do with"100abc","100abc". Should that still work? The old zend_get_parameters()following by a convert_to_long() says Yes. The newer zend_parse_parameters()says no.With new version it's possible to catch such typos, with old one they'd
just be silently ignored and perhaps could cause very hard to find bugs in
your code..

--Jani

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 Nov. 15, 2005 17:30:42

Rasmus L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


Pierre wrote:On Tue, 15 Nov 2005 09:17:20 -0800
(Rasmus Lerdorf) wrote:Pierre wrote:On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
(Jani Taskinen) wrote:If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)

Nothing to fix here, move along. (and fix your code..)PHP is losely typed, I see nothing wrong to pass an integer as
string there (for example, imagecreate("100", "100"); works).The question isn't what to do with "100","100" but what to do with"100abc","100abc". Should that still work? The oldzend_get_parameters() following by a convert_to_long() says Yes. Thenewer zend_parse_parameters() says no.My answer was to Jani's.I realize that, but Jani said "bad data" not data of the wrong type.Your example didn't have any bad data. You just had "100" which is aperfectly valid numeric string and will work in all cases.-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#10 Nov. 15, 2005 17:33:43

Rasmus L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] date() behaviour changed in 5.1?


Jani Taskinen wrote:On Tue, 15 Nov 2005, Rasmus Lerdorf wrote:Pierre wrote:On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
(Jani Taskinen) wrote:If you pass bad data to a function, it should not warn you?
I'd rather have it as a FATAL error. :)

Nothing to fix here, move along. (and fix your code..)PHP is losely typed, I see nothing wrong to pass an integer as string
there (for example, imagecreate("100", "100"); works).The question isn't what to do with "100","100" but what to do with"100abc","100abc". Should that still work? The oldzend_get_parameters() following by a convert_to_long() says Yes. Thenewer zend_parse_parameters() says no.With new version it's possible to catch such typos, with old one they'djust be silently ignored and perhaps could cause very hard to findbugs in your code..I suppose, but I still find it weird that:

date("h", (int)$foo);

and

date("h", $foo);will behave differently when $foo isn't a clean numeric string. Andwhen we move 100% to zend_parse_parameters() in PHP 6 there will be manymore functions changing their behaviour due to this.-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] date() behaviour changed in 5.1? [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of November
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support