Backport #1195: String#% does not include prefix before zero value for # versions of numeric formats

• Status: Rejected
• Assignee: -

[headius (Charles Nutter)]

=begin
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"
=end

[akr (Akira Tanaka)]

• Status changed from Open to Rejected

=begin

=end

[headius (Charles Nutter)]

=begin
Tanaka Akira wrote:

In article [e-mail],
Charles Nutter [e-mail] 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

=end

[headius (Charles Nutter)]

=begin
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.

=end

[matz (Yukihiro Matsumoto)]

=begin
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 [e-mail] 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.

=end

[headius (Charles Nutter)]

=begin
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

=end

[matz (Yukihiro Matsumoto)]

=begin
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 [e-mail] 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.

=end

[headius (Charles Nutter)]

=begin
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

=end