[#85940] [Ruby trunk Bug#14578] Forking a child process inside of a mutex crashes the ruby interpreter — ben.govero@...
Issue #14578 has been reported by bengovero (Ben Govero).
3 messages
2018/03/05
[#86205] [Ruby trunk Feature#14618] Add display width method to String for CLI — aycabta@...
Issue #14618 has been reported by aycabta (aycabta .).
3 messages
2018/03/19
[#86366] Re: [ruby-cvs:70102] usa:r63008 (trunk): get rid of test error/failure on Windows introduced at r62955 — Eric Wong <normalperson@...>
usa@ruby-lang.org wrote:
3 messages
2018/03/28
[ruby-core:86358] [Ruby trunk Bug#5304][Rejected] Array#pack handles objects for eg format 'E' differently than 1.8
From:
muraken@...
Date:
2018-03-28 07:41:25 UTC
List:
ruby-core #86358
Issue #5304 has been updated by mrkn (Kenta Murata).
Status changed from Assigned to Rejected
Rejected because this had already been meaningless now.
----------------------------------------
Bug #5304: Array#pack handles objects for eg format 'E' differently than 1.8
https://bugs.ruby-lang.org/issues/5304#change-71286
* Author: brixen (Brian Shirai)
* Status: Rejected
* Priority: Normal
* Assignee: mrkn (Kenta Murata)
* Target version:
* ruby -v: ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
In 1.9, Array#pack when passed an object that defines #to_f and one of the Float formats raises a TypeError. This is a change from 1.8. The code in 1.9 calls rb_to_float()
# 1.9
VALUE
rb_to_float(VALUE val)
{
if (TYPE(val) == T_FLOAT) return val;
if (!rb_obj_is_kind_of(val, rb_cNumeric)) {
rb_raise(rb_eTypeError, "can't convert %s into Float",
NIL_P(val) ? "nil" :
val == Qtrue ? "true" :
val == Qfalse ? "false" :
rb_obj_classname(val));
}
return rb_convert_type(val, T_FLOAT, "Float", "to_f");
}
The rb_to_float() imposes the (arbitrary) restriction that the object be kind of Numeric. The 1.8 pack code used rb_Float(), which merely requires the object respond to #to_f and return a Float.
The treatment of objects in 1.9 for the float formats is thus different than for eg the integer formats, where the object simply must respond to #to_int. The requirement that the object be a kind of Numeric breaks the uniform ducktyping and imposes an arbitrary and unnecessary type/class requirement.
Was this change intended, and if so, why? Apologies if this was discussed on ruby-core prior to the change; I could not find any discussion through searching.
The following code illustrates the issue:
o = Object.new
def o.to_int
puts "to_int called"
1
end
def o.to_f
puts "to_f called"
1.1
end
p [o].pack("I") # => "\001..." (depends on endianness)
p [o].pack("E") # => 1.8 - "<numbers>"; 1.9 - TypeError
$ ruby1.8.7 -v pack_test.rb
ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-darwin10.8.0]
to_int called
"\001\000\000\000"
to_f called
"\232\231\231\231\231\231\361?"
$ ruby1.9.2 -v pack_test.rb
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]
to_int called
"\x01\x00\x00\x00"
pack_test.rb:14:in `pack': can't convert Object into Float (TypeError)
from pack_test.rb:14:in `<main>'
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>