Project

General

Profile

Actions

Backport #5276

closed

4294967295.8.round is 4294967295 on 32bit

Added by naruse (Yui NARUSE) over 12 years ago. Updated over 12 years ago.

Status:
Closed
Assignee:
-
[ruby-core:39279]

Description

ruby -e'p 4294967295.8.round' must be 4294967296 but 4294967295 on 32bit environment.


Related issues 1 (0 open1 closed)

Related to Backport193 - Backport #5272: Float#round doesn't round big valuesClosed09/05/2011Actions

Updated by naruse (Yui NARUSE) over 12 years ago

Following RubySpec also fails on 32bit env.

Float#round rounds self to an optionally given precision FAILED
Expected 0.0
to equal 0.42

/home/chkbuild/build/ruby-trunk/20110905T070102Z/rubyspec/core/float/round_spec.rb:26:in block (3 levels) in <top (required)>' /home/chkbuild/build/ruby-trunk/20110905T070102Z/rubyspec/core/float/round_spec.rb:3:in <top (required)>'

Actions #2

Updated by marcandre (Marc-Andre Lafortune) over 12 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r33198.
Yui, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • numeric.c (flo_round): Fix criteria for 32 bits platform
    part 2 of [bug #5276]

Updated by marcandre (Marc-Andre Lafortune) over 12 years ago

Interestingly, the first bug is in dbl2ival, not in my patch. My patch just uncovered it. In particular:

0.59.divmod(7.761021455128987e-11).first #  => 7602092113 on 64 bits platform
                                         # but 7602092112 on 32 bits

This bug was incompletely addressed in r13902.

Fixed in r33198 and r33199.

Moving to backport.

Actions #4

Updated by marcandre (Marc-Andre Lafortune) over 12 years ago

  • Tracker changed from Bug to Backport
  • Status changed from Closed to Open

Updated by marcandre (Marc-Andre Lafortune) over 12 years ago

  • Assignee deleted (marcandre (Marc-Andre Lafortune))
Actions #6

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

If I parsed this thread correctly, this bug is not a regression. therefore it's no 1.9.3p0 matter.

Updated by marcandre (Marc-Andre Lafortune) over 12 years ago

Indeed, this is not a regression. Backports are not always regressions, though. Could you explain why you think that only regressions should be included in 1.9.3p0?

I feel that the bugs I found recently in {Float|Integer}#round (2 each) and the one in Float#divmod are perfect candidates to be included in 1.9.3 because

  • we are still in preview mode
  • these bugs are very localized and are highly unlikely to impact anything else
  • these bugs can have serious consequences for anyone dealing with calculations (scientific, etc...)

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

Indeed, this is not a regression. Backports are not always regressions, though.
Could you explain why you think that only regressions should be included in 1.9.3p0?

Yup. It depend on release schedule. If we have one month testing time,
all bugfixes should
be backported. but now we expected 1.9.3p0 will release very soon.
Actually, our release
schedule already have short delay.

I feel that the bugs I found recently in {Float|Integer}#round (2 each) and the one in Float#divmod are perfect candidates  to be included in 1.9.3 because

  • we are still in preview mode

Yes and no.
Yes, www.ruby-lang.org don't publish 1.9.3-rc1 yet.

However, at [ruby-core:39062], Yugui talked about she would like
to release r33028 as Ruby 1.9.3 RC1. therefore, almost all commiters stopped
to backport their bugfixes into ruby_1_9_3.

I hope you also follow their gentle developement.

Also, I'd like to explain two good high priority request example.

  1. [ruby-core:39268] Luis reported new regression and explained why
    it is high priority.
  2. [ruby-core:39298] Yui reported 1.9.3 + Xcode 4.2 Developer Preview
    7 don't work at all on Lion.

Both explained clearly why we need to take a risk.

  • these bugs are very localized and are highly unlikely to impact anything else

I have no objection. But, my point is, if we will backport all
localized bugs,
our code impact aren't localized anymore. Therefore we need to make
close out point.

Yugui said, ([ruby-core:39243])

Soon I'll start final check for release and I believe we can release Ruby 1.9.3
in this 1-2 weeks.

If a week before is not a good deadline, when should we close out no
urgent backport request?

  • these bugs can have serious consequences for anyone dealing with calculations (scientific, etc...)

It can. And almost all bugs can make serious fault. so, I don't
think it's a good threshold
for making backporting decision just before the release deadline.

Thank you.

Updated by kosaki (Motohiro KOSAKI) over 12 years ago

Also, I'd like to explain two good high priority request example.

  1.  [ruby-core:39268] Luis reported new regression and explained why
    it is high priority.
  2.  [ruby-core:39298] Yui reported 1.9.3 + Xcode 4.2 Developer Preview
    7 don't work at all on Lion.

Both explained clearly why we need to take a risk.

In the other hands, recent PHP mistake tell us which development shouldn't do.

https://threatpost.com/en_us/blogs/serious-crypto-bug-found-php-537-082211

short brief: one warnings was removed at last rc for php 5.3.7 and,
actually, its commit
has serious security hole regression.

That's why I want only regression and/or platform disaster patches are
backported.

Actions #10

Updated by naruse (Yui NARUSE) over 12 years ago

  • Target version deleted (1.9.3)
Actions #11

Updated by naruse (Yui NARUSE) over 12 years ago

  • Status changed from Open to Closed

This issue was solved with changeset r33899.
Yui, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


merge revision(s) 33198,33199:

* numeric.c (flo_round): Fix criteria for 32 bits platform
  part 2 of [bug #5276]

* numeric.c (dbl2ival): Fix Float#divmod and #round for 32 bit
  platform. part 1 of [bug #5276]
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0