-
Notifications
You must be signed in to change notification settings - Fork 7.9k
RFC: Raising zero to the power of negative number #13128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
754daee
to
fb149f6
Compare
fb149f6
to
ea8a19f
Compare
ea8a19f
to
c8c4d4b
Compare
Zend/zend_operators.c
Outdated
static zend_result safe_pow(double *result, double base, double exponent) | ||
{ | ||
if (base == 0.0 && exponent < 0.0) { | ||
zend_power_base_0_exponent_lt_eq_0_error(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should likely check for EG(exception)
and return FAILURE
in that case (for throwing error handlers). Usages of safe_pow
should propagate this return value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what I should change here. The changes should not throw an exception but the deprecation note. In PHP 9.0 it should throw an exception, but this PR is aimed at 8.4. The same note applies to your second comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warnings can be promoted from error handlers to exceptions. In these cases, often, the program flow must be adjusted in some way. Anyway, I looked at the way pow_function_base()
s return value is used, and apparently it indicates not whether the operation was successful, but whether the two operand types support the pow
operation. So a change is probably not necessary here.
661b445
to
620b2fd
Compare
@jorgsowa I'm assuming this is ready to have another look? |
Seems like the comments are still unaddressed. Please ping me once you've made the relevant changes, or if you need help with them. |
Thanks for review @iluuu1994. I changed the status to Draft to not take the time of the reviewers when the PR is not finished. Now I have added the function |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Thanks for the changes! You can ignore the nit, I'll adjust it before merging.
$values = [ | ||
234, | ||
-234, | ||
23.45e1, | ||
-23.45e1, | ||
0xea, | ||
0352, | ||
"234", | ||
"234.5", | ||
"23.45e1", | ||
true, | ||
false, | ||
pow(0, -2), | ||
acos(1.01), | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is an unrelated change: The array contents appear to be identical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true. I reformatted the code as I have already touched the file within PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated changes, such as this reformatting, make it harder to see what changed in the test over time, e.g. within the git blame
output: As a reader I would need to think whether the changes are significant or not. As an example, this change makes it harder to determine if this RFC added a new test case to properly cover the changed code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would be good to reformat all such tests in a separate PR? I also had some cases in the past when I was modifying existing tests and the code was not properly formatted so I just included this in PR. If we reformat everything at once then we don't have such discussions again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm generally against reformatting, but this formatting is just objectively bad. So, doing it in a separate PR makes sense to me.
$values = [ | ||
234, | ||
-234, | ||
23.45e1, | ||
-23.45e1, | ||
0xea, | ||
0352, | ||
"234", | ||
"234.5", | ||
"23.45e1", | ||
true, | ||
false, | ||
pow(0, -2), | ||
acos(1.01), | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto.
de1b634
to
2096685
Compare
I added an entry about deprecation to |
Either both NEWS and UPGRADING should be adjusted, or neither of them. Within NEWS, the [RFC] tag is not used historically and looks odd. |
@TimWolla thank your comments. I adjusted the entry in NEWS. I was following the existing tag in the file but changed to the more common convention. Also, I added an entry to the UPGRADING file. |
Thanks @jorgsowa! Merged without the formatting changes. I also fixed a small bug in |
Thank you for your help with this PR. I will prepare PR with the reformatting of those test snippets and will change my code style configuration. |
Fixes: #8015
RFC: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number
Based on the code: master...iluuu1994:php-src:throw-division-by-zero-on-pow-of-base-0-exponent-lt-eq-0