This changeset is to suppress clang's -Wimplicit-int-float-conversion
warning.
In 64 bit signed long and IEEE 754 double combination (== almost
everyone these days), LONG_MAX is 9,223,372,036,854,775,807. This
value is _not_ exactly representable by double. The nearest value
that a double can represnt is 9,223,372,036,854,775,808. It is one
greater than LONG_MAX. Let's call this value the "x".
The expression `LONG_MAX < yi` is a long versus double comparison.
According to ISO/IEC 9899:1999 Section 6.3.1.8 (that defines the
"usual rithmetic conversions"), The long value must first be casted
into double. Because FLT_ROUNDS is typically 1 ("round to the
nearest" mode), the conversion yields the "x" value shown above. So
the comparison is in fact `x < yi`.
This comparison is false for yi == x situation, i.e. yi is still
bigger than LONG_MAX. On such situation the `yn = (long)yi;`
statement that appear several lines below renders underfined
behaviour, as per ISO/IEC 9899:1999 Section 6.3.1.3.
To remedy, we just change the comparison from `<` to `<=` so that
yi == x situation can properly be handled.
Ko1 plans to implement Guild. That can interface the caching
mechanism introduced here. To prevent future breakage we would
better avoid rolling our own code here. Instead use the existing
vm_search_method() which would be modified by him.
This commit deletes some asserions, but they are in fact checked
inside of vm_search_method().
Why not cache the method entry at each caller site. The void**
is in fact a method entry, but this struct is hidden from ruby.h
so intentionally left opaque.
This was accidentally turned on because there was no checking for
Qundef.
Also, since only a single keyword is currently supported, simplify
the rb_get_kwargs call.
Previously, passing to_enum/enum_for a method that was defined in
Lazy itself returned wrong results:
[1,2,3].to_enum(:map).to_a
# => [1, 2, 3]
[1,2,3].lazy.to_enum(:map).to_a
# => []
I'm not sure why methods that are designed to be lazy do not work
with to_enum/enum_for. However, one possible way to work around
this bug is to have to_enum/enum_for use the implementation found
in Enumerable/Enumerator, which is what this commit does.
While this commit works around the problem, it is a band-aid, not a
real fix. It doesn't handle aliases of Enumerable::Lazy methods,
for instance. A better fix would be appreciated.
Previously, Enumerator::Lazy#with_index was not defined, so it
picked up the default implementation from Enumerator, which was
not lazy.
Based on earlier patch from nobu.
Fixes [Bug #7877]
for simplicity and consistency.
Now SUPPORT_JOKE needs to be prefixed with OPT_ to make the config
visible in `RubyVM::VmOptsH`, and the inconsistency was introduced.
As it has never been available for override in configure (no #ifndef
guard), it should be fine to rename the config.
On Solaris, it seems that the select(3C) in this test works only
when sending 1 byte out-of-band data, though I cannot investigate
the cause. The behavior is observed on a Solaris 10 server in
addition to Solaris 11 on which the test had been skipped.