Backport #1195
String#% does not include prefix before zero value for # versions of numeric formats
| Status: | Rejected | Start date: | 02/23/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
Ruby 1.8.7:
$ /opt/local/bin/ruby -e "p('%#b %#B %#o %#x %#X' % [0,0,0,0,0])"
"0b0 0B0 00 0x0 0X0"
Ruby 1.9.1p0:
$ ruby1.9 -e "p('%#b %#B %#o %#x %#X' % [0,0,0,0,0])"
"0 0 0 0 0"
History
Updated by akr (Akira Tanaka) about 3 years ago
- Status changed from Open to Rejected
Updated by headius (Charles Nutter) about 3 years ago
Tanaka Akira wrote: > In article <49a25ec0ce233_84c7e8c1f8909a@redmine.ruby-lang.org>, > Charles Nutter <redmine@ruby-lang.org> writes: > >> Bug #1195: String#% does not include prefix before zero value for # versions of numeric formats > > It's intentional. So then the Ruby 1.8 behavior is a bug. Can we move the bug to Ruby 1.8? I think the title and description don't even need to be changed. I have added a spec for this behavior with a 1.9 guard, but I could remove that guard and make it a ruby_bug instead. - Charlie
Updated by headius (Charles Nutter) about 3 years ago
Akinori MUSHA wrote: > When 0b0, 0B0, 00, 0x0, and 0X0 are all perfectly human readable and > machine parsable, I'm not sure if we should tag it a bug and get it > fixed in any of those 1.8 branches at the cost of breaking > compatibilities. > > How does it work in JRuby 1.8? We implemented our own sprintf that matches Ruby (and in places, C) behavior. We can make it work either way. Currently there's logic that chooses the 1.8 behavior in 1.8 mode and the 1.9 behavior in 1.9 mode. I primarily ask because either there's a reason it changed (in which case 1.8 should eventually change too) or there's no reason it changed (in which case...why did it change?). It would be easier to maintain one behavior and not have the move from 1.8 to 1.9 behave differently.
Updated by matz (Yukihiro Matsumoto) about 3 years ago
Hi, In message "Re: [ruby-core:22406] Re: [Bug #1195] String#% does not include prefix before zero value for # versions of numeric formats" on Tue, 24 Feb 2009 16:09:03 +0900, Charles Oliver Nutter <charles.nutter@sun.com> writes: |I primarily ask because either there's a reason it changed (in which |case 1.8 should eventually change too) or there's no reason it changed |(in which case...why did it change?). It would be easier to maintain one |behavior and not have the move from 1.8 to 1.9 behave differently. Ruby 1.8 uses underlying sprintf() where 1.9 uses its own implementation. So, in short, choose 1.9 behavior. matz.
Updated by headius (Charles Nutter) about 3 years ago
Yukihiro Matsumoto wrote: > Ruby 1.8 uses underlying sprintf() where 1.9 uses its own > implementation. So, in short, choose 1.9 behavior. Given that, I think leaving it specified as a new behavior in 1.9 is best. (i.e. 1.8 behavior is not a bug, since it's just default sprintf). - Charlie
Updated by matz (Yukihiro Matsumoto) about 3 years ago
Hi, In message "Re: [ruby-core:22421] Re: [Bug #1195] String#% does not include prefix before zero value for # versions of numeric formats" on Wed, 25 Feb 2009 02:38:55 +0900, Charles Oliver Nutter <charles.nutter@sun.com> writes: |Yukihiro Matsumoto wrote: |> Ruby 1.8 uses underlying sprintf() where 1.9 uses its own |> implementation. So, in short, choose 1.9 behavior. | |Given that, I think leaving it specified as a new behavior in 1.9 is |best. (i.e. 1.8 behavior is not a bug, since it's just default sprintf). It's up to you. 1.8 behavior is not a bug, it's just one of implementation dependent behavior of sprintf() on your platform, as far as I understand. 1.8 may work like 1.9 on some platforms. matz.
Updated by headius (Charles Nutter) about 3 years ago
Yukihiro Matsumoto wrote: > It's up to you. 1.8 behavior is not a bug, it's just one of > implementation dependent behavior of sprintf() on your platform, as > far as I understand. 1.8 may work like 1.9 on some platforms. Thank you for the clarification. I'll talk with Brian about how best to represent this in the specs. - Charlie