Project

General

Profile

Backport #4952

Integer#chr(Encoding::*) behaves inconsistently with negative or large values

Added by Nevir (Ian MacLeod) over 8 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
[ruby-core:37699]

Description

These seem like they should all be raising RangeError; and appear to indicate that values are overflowing/being cast improperly:

ruby-1.9.2-p180 :001 > -1.chr(Encoding::UTF_8)
 => "\xFF" 
ruby-1.9.2-p180 :002 > -2.chr(Encoding::UTF_8)
 => "\xFE" 
ruby-1.9.2-p180 :006 > -1.chr(Encoding::UTF_16LE)
 => "\uD7BF\xFF\xDF" 
ruby-1.9.2-p180 :007 > -2.chr(Encoding::UTF_16LE)
 => "\uD7BF\xFE\xDF" 
ruby-1.9.2-p180 :008 > -1234.chr(Encoding::UTF_16LE)
 => "\uD7BE\x2E\xDF"
ruby-1.9.2-p180 :009 > -1.chr(Encoding::EUC_JP)
ArgumentError: invalid codepoint 0xffffffff in EUC-JP

Examples that are inconsistent:

ruby-1.9.2-p180 :005 > -1.chr(Encoding::WINDOWS_1251)
RangeError: 4294967295 out of char range

Examples that seem to be fine:

ruby-1.9.2-p180 :003 > -3.chr(Encoding::UTF_8)
RangeError: -3 out of char range

History

Updated by Nevir (Ian MacLeod) over 8 years ago

This appears to be related to and likely a duplicate of http://redmine.ruby-lang.org/issues/4869

#2

Updated by nobu (Nobuyoshi Nakada) over 8 years ago

  • Tracker changed from Bug to Backport
  • Project changed from Ruby master to Backport192

In the trunk, it has been fixed by r29483.

#3

Updated by naruse (Yui NARUSE) over 3 years ago

  • Status changed from Open to Rejected

Also available in: Atom PDF