Skip to content

Fix GH-14709 overflow on recurrences for DatePeriod::__construct - #14710

Closed
devnexen wants to merge 1 commit into
php:PHP-8.3from
devnexen:gh14709
Closed

devnexen wants to merge 1 commit into
php:PHP-8.3from
devnexen:gh14709

Conversation

@devnexen

Copy link
Copy Markdown
Member

No description provided.

@devnexen

Copy link
Copy Markdown
Member Author

Note : apparently needs adaptation with higher branches.

@devnexen devnexen changed the title Fix GH-14709 overflow on reccurences for DatePeriod::__construct Fix GH-14709 overflow on recurrences for DatePeriod::__construct Jun 29, 2024
@devnexen
devnexen requested a review from ndossche June 29, 2024 15:23

@ndossche ndossche left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more or less right: recurrences is an int in _php_period_obj so we can't store a higher number. The issue isn't fully solved though because if include_start_date and include_end_date are set then you still get an integer overflow because you can add 2 to INT_MAX.

@ndossche

Copy link
Copy Markdown
Member

From a technical PoV this is right and stops the undefined behaviour.
Me being pragmatic I think I would've just capped it at INT_MAX-2 because we don't lose much here. It would be a simpler patch.
I don't know what Derick prefers, I'm leaving the decision to him as this is his ext, not mine.

@devnexen

Copy link
Copy Markdown
Member Author

in fact I tried to separate to let know of the second edge case separately but yes it s not so urgent anyway we ll see :).

@derickr derickr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with @nielsdos here — capping it at INT_MAX - 8 (in case we get further options), seems perfectly cromulent.

Comment thread ext/date/php_date.c Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

between 1 is ambiguous between > 1 or >= 1. Please be precise.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's standard wording (and always refers to the closed interval). cc @Girgias

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have always used it to mean an inclusive range AFAIK.

Might help to have helper functions for this, similar to what I did for ValueErrors which are empty.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should I revert back to the previous wording ?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe wait a while on @derickr's opinion.

Comment thread ext/date/tests/gh14709.phpt Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is superfluous. Doesn't the test run fine on 32bit platforms, too?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not recall why, usually I do not disable for 32 bits just like this. I ll give it a go in a bit later.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems working indeed, might had been just a case I forgot to remove after code changes.

@cmb69

cmb69 commented Dec 3, 2024

Copy link
Copy Markdown
Member

This should not be applied to PHP-8.2 any longer.

@devnexen

devnexen commented Dec 3, 2024

Copy link
Copy Markdown
Member Author

Ah good point, time flies :)

@derickr derickr left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks OK as is, but please squash the commits first, and rebase for PHP 8.3.

Comment thread ext/date/php_date.c Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why you removed the specific extension here? We had an RFC for this:

https://wiki.php.net/rfc/datetime-exceptions

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/extension/exception ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok I see, going to fix these..

Comment thread ext/date/php_date.c Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: No need to add empty lines

Comment thread ext/date/php_date.c Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also use the specific extension here again.

Comment thread ext/date/tests/gh14709.phpt Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add the exception class, like in the other tests, by using:

echo $e::class, ': ', echo $e->getMessage() . PHP_EOL;

@derickr derickr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but please address my last nit. And then also please squash before merging.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: extraneous line at end of file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Signed integer overflow in ext/date/php_date.c

5 participants