Front page | perl.perl5.porters |
Postings from August 2019
On Mon, Aug 19, 2019 at 10:53 PM Tony Cook via RT
<perlbug-followup@perl.org> wrote:
>
> On Fri, 28 Jun 2019 03:36:08 -0700, sisyphus@cpan.org wrote:
> > On Thu, 27 Jun 2019 22:34:32 -0700, ikegami@adaelis.com wrote:
> > > Changing this means changing Scalar::Util::looks_like_number. Would
> > > that
> > > break things?
> >
> > I agree that looks_like_number()also needs to be thought about.
> >
> > Perl's current behaviour is to issue the "isn't numeric" warning when
> > "0xff"+0 is evaluated.
> > However, I doubt that such a warning is valid now that "0xff" is
> > numified to 255.
> > It was certainly a valid warning when "0xff" numified to 0 ... but I'm
> > thinking that warning should not be emitted for the current behaviour,
> > and nor should looks_like_number("0xff") return FALSE.
>
> I don't think looks_like_number() needs to change - I think C<"0xff"> needs to return to numerically evaluating as 0, pre the attached.
Why did this behaviour change? Was it intentional or a side effect?
I have bisected it down to this commit (between the 5.29.1 and 5.29.2 releases):
----
commit ce6f496d720f6206455628425320badd95b07372 (HEAD, refs/bisect/bad)
Author: sisyphus <sisyphus1@optusnet.com.au>
Date: 2018-08-01 22:33:38 +1000
PATCH: [perl #41202] text->float gives wrong answer
This changes to use Perl_strtod() when available, and that turns out to
be the key to fixing this bug.
S_mulexp10() is removed from embed.fnc to avoid repeating the
complicated prerequisites for defining Perl_strtod(). This works
because this static function already was defined before use in
numeric.c, and always called in full form without using a macro.
James Keenan fixed a file permissions problem originally introduced by
this commit, but the fix has been squashed into it.
----
Thread Previous
|
Thread Next