Backport #5276: 4294967295.8.round is 4294967295 on 32bit

• Status: Closed
• Assignee: -

[naruse (Yui NARUSE)]

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

[naruse (Yui NARUSE)]

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)>'

[marcandre (Marc-Andre Lafortune)]

• 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]

[marcandre (Marc-Andre Lafortune)]

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.

[marcandre (Marc-Andre Lafortune)]

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

[marcandre (Marc-Andre Lafortune)]

• Assignee deleted (marcandre (Marc-Andre Lafortune))

[kosaki (Motohiro KOSAKI)]

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

[marcandre (Marc-Andre Lafortune)]

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...)

[kosaki (Motohiro KOSAKI)]

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.

[kosaki (Motohiro KOSAKI)]

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.

[naruse (Yui NARUSE)]

• Target version deleted (1.9.3)

[naruse (Yui NARUSE)]

• 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]