Front page | perl.perl5.porters |
Postings from April 2019
On 4/16/19 7:06 AM, sisyphus wrote:
>
> I see that line 6555 of perl.h is presently:
> #define Perl_strotod(s, e) \
>
> I wonder if that was meant to be:
> #define Perl_strtod(s, e) \
>
> (I'll test it.)
Yes, that's the typo. But fixing it opens a can of worms.
Which I believe I have fixed in
https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-strtod
Please check it out.
>
> Cheers,
> Rob
>
>
> On Tue, Apr 16, 2019 at 10:26 PM sisyphus <sisyphus359@gmail.com
> <mailto:sisyphus359@gmail.com>> wrote:
>
> James,
> Does the following behave as desired ?
>
> #####################
> use warnings;
> use Inline C => <<'EOC';
> int foo() {
> #ifdef Perl_strtod
> return 0;
> #else
> return 1;
> #endif
> }
> EOC
> exit(foo());
> ####################
>
> Cheers,
> Rob
>
> On Tue, Apr 16, 2019 at 9:59 PM James E Keenan <jkeenan@pobox.com
> <mailto:jkeenan@pobox.com>> wrote:
>
> On 4/16/19 4:53 AM, sisyphus wrote:
> > Something in the last couple of days has definitely caused a
> reversion
> > to use of perl's atof().
> >
> > This Inline::C script:
> > ########################
> > use warnings;
> > use Inline C => <<'EOC';
> > void foo() {
> > #ifdef Perl_strtod
> > printf("Perl_strtod defined\n");
> > #else
> > printf("Perl_strtod NOT defined\n");
> > #endif
> > }
> > EOC
> > foo();
> > ########################
> >
>
> I can confirm this result on Linux.
>
> Is there any way your C program could be rewritten such that we
> get a
> Perl exit 0 on defined and a Perl exit 1 on NOT defined? If we had
> that, then we could plug it into Porting/bisect.pl
> <http://bisect.pl>.
>
>
> > reports (on all of my Windows and Linux builds) that current
> blead has
> > Perl_strtod NOT defined.
> > If Perl_strtod is not defined then I don't think that
> Perl_strtod can be
> > assigning the values - it must surely be perl's atof() that's
> doing the
> > assigning.
> >
> > My -Dusequadmath builds are also afflicted with the issue (as
> they now
> > also do not define Perl_strtod). That's not a reversion -
> this is the
> > first time ever that quadmath builds have used perl's atof(),
> and the
> > result is not pretty.
> >
> > Anyway - perhaps it's not your commit that's the culprit.
> > It has to be something fairly recent because I built blead a
> couple of
> > days ago and it was fine. (My builds do check that
> > strtod/strtold/strtoflt128 are being used.)
> > I haven't even yet glanced at the current perl source. I've
> instead been
> > trying to gauge the scope of the breakage - which is
> something that took
> > me far longer than it ought.
> >
> > I'll prepare and post that patch to posix.t tonight, and try
> to get my
> > head around the perl source tomorrow.
> >
> > Cheers,
> > Rob
> >
> > On Tue, Apr 16, 2019 at 1:50 PM Karl Williamson
> <public@khwilliamson.com <mailto:public@khwilliamson.com>
> > <mailto:public@khwilliamson.com
> <mailto:public@khwilliamson.com>>> wrote:
> >
> > On 4/15/19 8:39 PM, sisyphus wrote:
> > > Unfortunately this latest commit
> > > (4ac6fab20b8950ee14756c6f2438809c572082cd) gets us
> back to assigning
> > > values incorrectly. (Perl's test suite will not
> presently detect
> > this.)
> > > I guess we've now somehow gone back to using perl's atof()
> > function for
> > > assignment of floating point values.
> > > At least, it seems that the values being assigned are
> now the
> > same as
> > > the values that perl's atof() assigns.
> >
> > I re-inspected the patch and don't see anyway that it
> could have made
> > this switcheroo.
> > >
> > > A quick check that will catch the problem is to run
> something like:
> > > $ perl -MPOSIX -le 'print "wtf" if
> POSIX::strtod("8.87359152e-6") !=
> > > 8.87359152e-6;'
> > >
> > > When nvtype is 'double, the value of 8.87359152e-6 is
> assigned
> > > incorrectly by perl's atof on a number of platforms,
> including
> > Windows
> > > and Linux - so it's a good value to test.
> > >
> > > Perhaps we should even add that test to the POSIX test
> suite ?
> > > We'd need to test a different value for
> -Duselongdouble builds -
> > I'll
> > > write a patch for posix.t and submit it later today in
> a separate
> > bug
> > > report.
> >
> > That sounds good.
> >
> > > That way, if Perl_strtod() is defined but perl's
> atof() is being
> > used,
> > > we'd find out about it when perl's test suite is run.
> > >
> > > Cheers,
> > > Rob
> > >
> > > On Tue, Apr 16, 2019 at 7:53 AM Karl Williamson via RT
> > > <perlbug-followup@perl.org
> <mailto:perlbug-followup@perl.org>
> <mailto:perlbug-followup@perl.org
> <mailto:perlbug-followup@perl.org>>
> > <mailto:perlbug-followup@perl.org
> <mailto:perlbug-followup@perl.org>
> > <mailto:perlbug-followup@perl.org
> <mailto:perlbug-followup@perl.org>>>> wrote:
> > >
> > > This should be fixed by
> > > commit 4ac6fab20b8950ee14756c6f2438809c572082cd
> > > Author: Karl Williamson <khw@cpan.org
> <mailto:khw@cpan.org> <mailto:khw@cpan.org <mailto:khw@cpan.org>>
> > <mailto:khw@cpan.org <mailto:khw@cpan.org>
> <mailto:khw@cpan.org <mailto:khw@cpan.org>>>>
> > > Date: Mon Apr 15 11:10:31 2019 -0600
> > >
> > > PATCH: [perl #133945] Perl_strtod failures
> > >
> > > This commit wraps Perl_strtod() in macros
> that cause the
> > > proper radix
> > > character to be used.
> > >
> > > --
> > > Karl Williamson
> > >
> > > ---
> > > via perlbug: queue: perl5 status: open
> > > https://rt.perl.org/Ticket/Display.html?id=133945
> > >
> >
>
Thread Previous
|
Thread Next