fix heuristics for setsockopt's OPTVAL argument #18761
Conversation
@t-a-k, this pull request has not received any support since being made in May 2021. It has acquired merge conflicts. Do you still want to pursue it? |
|
I believe this should be changed to only check SvPOK. It never should have been checking the private flag to begin with, and on 5.36+ that change would also prevent it from inadvertently being treated as a string. |
|
I'm sorry for leaving this PR unmaintained. I will merge it with blead and push again. |
Thanks for your comment. I've changed the patch to check SvPOK and pushed it. I also added a test for #19892 which I believe this PR will fix. |
|
This will treat boolean values as a string, which I don't think is desirable. You can check for that with SvIsBOOL(sv). It also needs to be rebased. |
setsockopt (pp_ssockopt) used to treat its last argument (OPTVAL) as a packed string whenever it has string slot set (SvPOKp), but this would be confused if the argument is an integer but had cached stringified value. Now it will treat OPTVAL as a packed string only when it is originally created as a string, using Perl 5.36+'s new (internal) feature where POK flag indicates whether the SV started as a string. Will fix GH Perl#18642.
Boolean values used to be treated as string, but this is not desirable. (thanks to @tonycoz) Also added tests for this.
|
Thank you for your advice. I've modified and rebased the patch and force-pushed it. |
4 participants
pp_ssockoptused to treat its last argument (OPTVAL) as a packed string whenever it has string slot set (SvPOKp), but this would be confused if the argument is an integer but had cached stringified value.This PR will make it treat
OPTVALas a packed string only when it does not contain any valid public numeric value.Will fix #18642.