Fix an edge case of non-Int being wrongly validated as Int#103
Open
gugod wants to merge 8 commits intoxslate:masterfrom
Open
Fix an edge case of non-Int being wrongly validated as Int#103gugod wants to merge 8 commits intoxslate:masterfrom
gugod wants to merge 8 commits intoxslate:masterfrom
Conversation
This is originally identified by @Ovid as a bug in Type::Tiny::XS: If I call int($num) on a floating point number, that number is subsequently identified as an integer, even when it's not. I suspected this is because the pIOK flag is set, but this might be a red herring (more later). Here's sample code which fails on every version (even .001) of Type:Tiny::XS that I've tested. See: tobyink/p5-type-tiny-xs#8 But it turns out it is also reproducble with Mouse::XS -- not with Mouse::PurePerl though.
... with different kinds of ways to initialize a scalar varible with "number" inside.
As @haarg demonstrated in tobyink/p5-type-tiny-xs#9, previous "fix" breaks for large unsigned integers. @haarg also pointed out that macro ended with "p" such as SvIOKp should be avoided, since that check the flag for ["non-public integer values"][1], and the one without p ("SvIOK") checks the flag for ["public integer values"][2] [1]: https://perl5.git.perl.org/perl.git/blob/HEAD:/sv.h#l369 [2]: https://perl5.git.perl.org/perl.git/blob/HEAD:/sv.h#l364
gugod
changed the title
Author
|
https://metacpan.org/changes/distribution/Type-Tiny-XS#L9 Latest release of Type::Tiny::XS already include the same changes. |
Member
|
@gugod Can you take a look at CI failures? |
Author
This reverts commit 6d9d779. It is unclear what kind of fixes are needed yet, we shall review this topic latter.
Author
|
https://travis-ci.org/gugod/p5-Mouse/builds/582260726 I tweaked travis config to run this branch with all stable versions. It looks like this PR cannot be directly applied for perl5 versions older than perl-5.18. I'll see what I can do keep them supported. |
This commit fix tests related to validate Int in tied array/scalar, on perl5.8 ... perl5.16. The 2 types of magic SVs are: 1. SvTYPE(sv) == SVt_PVMG 2. SvMAGIC(sv) It appears to me that, when they are assigned integer values, -- even if it's originated from integer literals -- there are no "public integer" inside these magical SV, only "private" ones. We have been using SvIOKp(sv) to probe the Integer-ness of an SV and that just happen to be seemingly the only ways to do so for magic SVs.
Author
|
@skaji The latest commit fix the regressions. There were all related to magic SVs and evidently magic SVs effect SV flags differently in new perl versions. At the end, passed for all perl versions: https://travis-ci.org/gugod/p5-Mouse/builds/582310868 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is basically a port of the issue #8 in Type::Tiny::XS repo as well as PR #9 to Mouse::XS.
The newly added test file includes the fail test cases provided by @Ovid and @haarg. I expend it to include some other scenarios too.