overflow in tm2unixtime:39:6

[chongwick]

Description

The following code:

<?php
$a = PHP_INT_MIN;
$b = PHP_FLOAT_MIN;
$c = date('Y-m-d H:i:s', gmmktime($a, $a, $a, $a, $a, $a));
echo $c;
?>

Resulted in this output:

/home/dan/php-8.3.9/ext/date/lib/tm2unixtime.c:39:6: runtime error: signed integer overflow: -9223372036854775808 - 153722867280912931 cannot be represented in type 'long long int'

PHP Version

8.3.9

Operating System

No response

[SakiTakamachi]

@chongwick
Is the reproduction code correct? Looks like $b is not used.

[DanielEScherzer]

@chongwick Is the reproduction code correct? Looks like $b is not used.

No $b needed, I can reproduce with

<?php
gmmktime(PHP_INT_MIN, PHP_INT_MIN, PHP_INT_MIN, PHP_INT_MIN, PHP_INT_MIN, PHP_INT_MIN);

maybe combine this with #16035 which is basically the same thing, just with some maximums rather than minimums?

[iluuu1994]

@chongwick Thank you for the reports! Since you created a few of those: I'm assuming this is a fundamental issue in the date lib, currently. If many more of these occur, I'm not sure if it makes sense to report all of them, until the issue is fixed.

[cmb69]

@iluuu1994, I think that at least for some functions/methods, we should reject out of range values right away, before even calling into timelib. E.g. #16048; it makes not much sense to even attempt to calculate the sunset for timestamps lying 292 billion years in the future, and it doesn't make any sense to calculate the sunset for timestamps where earth didn't even exist.

[iluuu1994]

But my time machine software written in PHP must support traveling 292 billion years into the future! Please support this use-case!

[MarcusXavierr]

@cmb69 When you say "reject out-of-range values right away", do you mean to raise an error when an overflow is detected as soon as possible, or to ignore the overflow and set some arbitrary value?

[cmb69]

@MarcusXavierr, the former. The function could throw a ValueError in that case.