Issue #15460 has been updated by shyouhei (Shyouhei Urabe).


I feel sorry for the situation.  I didn't expect any actual usage of that corner case.

However the previous behaviour was strange.  It did actually raise exception when you pass a very huge number to it:

```
% ruby -v -e 'p IO.pipe[0].ungetbyte(18446744073709551616)'
ruby 1.9.3p551 (2014-11-13) [x86_64-darwin15.6.0]
-e:1:in `ungetbyte': can't convert Bignum into String (TypeError)
        from -e:1:in `<main>'
```

The "TypeError" in the error message is because the testing ruby is old.  Now that Bignum is wiped out, I don't think this restriction is reasonable.

----------------------------------------
Bug #15460: Behaviour of String#setbyte changed
https://bugs.ruby-lang.org/issues/15460#change-75898

* Author: gettalong (Thomas Leitner)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
I just installed Ruby 2.6.0 for benchmarking reasons and found that the change [string.c: setbyte silently ignores upper bits](https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/65804) broke my library/application HexaPDF.

Before using String#setbyte I tested how it would respond to values lower than 0 or greater than 255 and found that it automatically performed the needed modulo 256 operation (at least up to Ruby 2.5.3). Therefore I left out the explicit modulo operation for performance reasons.

Would it make sense to change the String#setbyte implementation to perform the modulo operation? This would restore compatibility with prior Ruby versions and may be what people would expect.



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