Bug #407

String#<<

Added by Shyouhei Urabe over 6 years ago. Updated about 4 years ago.

[ruby-dev:35789]
Status:Closed
Priority:Normal
Assignee:Yui NARUSE
ruby -v: Backport:

Description

=begin
以下のようにtrunkの振る舞いは1.8以前と違うのですが、これは1.8
の振る舞いのほうが自然ではないでしょうか? 256が\00になるのは
UTF-8としてもASCII-7BITとしてもなんかおかしい気がします。

% trunk/bin/ruby -Ku -ve'p "ABC" << 256'
ruby 1.9.0 (2008-08-06 revision 17576) [x86_64-linux]
"ABC\x00"
% ruby_1_8/bin/ruby -Ku -ve'p "ABC" << 256'
ruby 1.8.7 (2008-08-06 revision 17572) [x86_64-linux]
-e:1:in `<<': can't convert Fixnum into String (TypeError)
from -e:1
=end

Associated revisions

Revision 39139
Added by Eric Hodel about 2 years ago

  • lib/rubygems/dependency_installer.rb: Only install local gems if they end in '.gem'. Fixes github rubygems issue #407.
  • test/rubygems/test_gem_dependency_installer.rb: Test for the above.

Revision 39139
Added by Eric Hodel about 2 years ago

  • lib/rubygems/dependency_installer.rb: Only install local gems if they end in '.gem'. Fixes github rubygems issue #407.
  • test/rubygems/test_gem_dependency_installer.rb: Test for the above.

History

#1 Updated by Shyouhei Urabe over 6 years ago

  • Category set to M17N

=begin

=end

#2 Updated by Yui NARUSE over 6 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

=begin
Applied in changeset r18399.
=end

#3 Updated by Yukihiro Matsumoto over 6 years ago

=begin
まつもと ゆきひろです

このチケットに関連してると思うのですが、

|> % ruby19 -Ku -ve'p "ABC" << 256'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> -e:1:in `': 256 out of char range (RangeError)
|>
|> UTF-8 だとこんな感じ。
|> % ruby19 -Ku -ve's="ABC\u3042" << 256;puts s.dump'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> "ABC\xE3\x81\x82\xC4\x80"
|
|この1.9の振る舞いはうれしくないんじゃないかな。
|"ASCII Compatible"の定義とかをよーく考えると、ASCIIの文字列とそうじゃな
|い文字列はこの場合同じ振る舞いになるべき(黙って大きい方のエンコーディン
|グに揃えるか、一律にエラー)と思いますよ。
|# じゃないと激しく使いづらすぎてかなわん。

という指摘がありました。個人的には現状以外の振る舞いが適切だ
とは思わないのですが、「compatibleなはずなのに振る舞いが違う
のは変」という認知は理解できないでもないです。

=end

#4 Updated by Yui NARUSE over 6 years ago

=begin
Yukihiro Matsumoto さんは書きました:

まつもと ゆきひろです

このチケットに関連してると思うのですが、

|> % ruby19 -Ku -ve'p "ABC" << 256'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> -e:1:in `': 256 out of char range (RangeError)
|>
|> UTF-8 だとこんな感じ。
|> % ruby19 -Ku -ve's="ABC\u3042" << 256;puts s.dump'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> "ABC\xE3\x81\x82\xC4\x80"
|
|この1.9の振る舞いはうれしくないんじゃないかな。
|"ASCII Compatible"の定義とかをよーく考えると、ASCIIの文字列とそうじゃな
|い文字列はこの場合同じ振る舞いになるべき(黙って大きい方のエンコーディン
|グに揃えるか、一律にエラー)と思いますよ。
|# じゃないと激しく使いづらすぎてかなわん。

という指摘がありました。個人的には現状以外の振る舞いが適切だ
とは思わないのですが、「compatibleなはずなのに振る舞いが違う
のは変」という認知は理解できないでもないです。

「黙って大きい方のエンコーディングに揃える」、が現在の動きの意図でしょう。

% ruby19 -Ku -e'
p "\u3042" << 0x3044
p "ABCDEF".force_encoding("UTF-8") << 0x3044
p "ABCDEF" << 0x3044'

"あい"
"ABCDEFい"
-e:3:in `': 256 out of char range (RangeError)

しかし、並べてみると確かにこれはおかしな挙動で、
これの原因は思うに ASCII Compatible 云々でなく、
スクリプト内の 7bit clean な String の encoding を US-ASCII にしている点
のような気がします。

=end

#5 Updated by Yukihiro Matsumoto over 6 years ago

=begin
まつもと ゆきひろです

In message "Re: Re: Ruby 1.9 - Bug #407 String#<<"
on Fri, 19 Sep 2008 21:53:10 +0900, "NARUSE, Yui" naruse@airemix.jp writes:

|% ruby19 -Ku -e'
|p "\u3042" << 0x3044
|p "ABCDEF".force_encoding("UTF-8") << 0x3044
|p "ABCDEF" << 0x3044'
|
|"あい"
|"ABCDEFい"
|-e:3:in `': 256 out of char range (RangeError)
|
|しかし、並べてみると確かにこれはおかしな挙動で、
|これの原因は思うに ASCII Compatible 云々でなく、
|スクリプト内の 7bit clean な String の encoding を US-ASCII にしている点
|のような気がします。

前からうすうす思っていたのですが、7bitフラグがある以上、わざ
わざUS-ASCIIにする必要はなかったのかもしれませんね。

それはそれとして、この仕様は

  • そもそも整数をconcatするのはおかしい
  • 1.9では?aはすでに文字列になっている

の二点から考えるに

  • 文字列への整数のconcatは禁止
  • または0..256の範囲だけ許可(互換性重視)

のいずれかの対応が良いような気がします。

まとめ:

1.9.1直前ですが、以下の二つを提案します。

  • 7bit文字列のエンコーディングを特別扱いしない
  • String#<<での整数の特別扱いをやめる

=end

#6 Updated by Yui NARUSE over 6 years ago

=begin
成瀬です。

Yukihiro Matsumoto さんは書きました:

それはそれとして、この仕様は

  • そもそも整数をconcatするのはおかしい
  • 1.9では?aはすでに文字列になっている

の二点から考えるに

  • 文字列への整数のconcatは禁止
  • または0..256の範囲だけ許可(互換性重視)

のいずれかの対応が良いような気がします。

まとめ:

1.9.1直前ですが、以下の二つを提案します。

  • 7bit文字列のエンコーディングを特別扱いしない

こちらは賛成です、やっときます。

  • String#<<での整数の特別扱いをやめる

確かに「文字列」としての String では String#<<Integer は異様な存在なんで
すが、
「バイト列」や「コードポイント列」として扱う場合には有効な機能なので、
Binarian や Unicoder は困りそうです。
現状、String#setbyte では追加ができませんし、できるようにしたとしても、
str.setbyte(str.length, 0x41) というのもちょっと、なので。

=end

#7 Updated by Martin Dürst over 6 years ago

=begin
At 08:00 08/09/20, NARUSE, Yui wrote:

成瀬です。

Yukihiro Matsumoto さんは書きました:

  • String#<<での整数の特別扱いをやめる

確かに「文字列」としての String では String#<<Integer は異様な存在なんで
すが、
「バイト列」や「コードポイント列」として扱う場合には有効な機能なので、
Binarian や Unicoder は困りそうです。
現状、String#setbyte では追加ができませんし、できるようにしたとしても、
str.setbyte(str.length, 0x41) というのもちょっと、なので。

成瀬さんと同意です。しばらく残して、様子を見たらどうでしょうか。

宜しくお願いします。 Martin.

#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp

=end

#8 Updated by Yukihiro Matsumoto over 6 years ago

=begin
まつもと ゆきひろです

In message "Re: Re: Ruby 1.9 - Bug #407 String#<<"
on Sat, 20 Sep 2008 16:02:58 +0900, Martin Duerst duerst@it.aoyama.ac.jp writes:

|>「バイト列」や「コードポイント列」として扱う場合には有効な機能なので、
|>Binarian や Unicoder は困りそうです。
|>現状、String#setbyte では追加ができませんし、できるようにしたとしても、
|>str.setbyte(str.length, 0x41) というのもちょっと、なので。
|
|成瀬さんと同意です。しばらく残して、様子を見たらどうでしょうか。

まあ、同じような文字列で一方がUS-ASCII、もう一方がUTF-8とい
うようなケースはなくなりましたから、様子を見ましょうか。

=end

#9 Updated by Yukihiro Matsumoto over 6 years ago

=begin
まつもと ゆきひろです

In message "Re: Re: Ruby 1.9 - Bug #407 String#<<"
on Sat, 20 Sep 2008 19:25:30 +0900, Tanaka Akira akr@fsij.org writes:

|> まあ、同じような文字列で一方がUS-ASCII、もう一方がUTF-8とい
|> うようなケースはなくなりましたから、様子を見ましょうか。
|
|エンコーディングが指定されていないファイルに記述された文字列
|は US-ASCII になるので、問題はむしろわかりにくくなっているよ
|うな気がしますけどねぇ。

US-ASCIIの文字列がまぎれ込むのを禁止できないと言う点では、問
題が解決していないというのは理解できますが、「むしろわかりに
くくなっている」というのはどういうことでしょう。

=end

#10 Updated by Yukihiro Matsumoto over 6 years ago

=begin
まつもと ゆきひろです

In message "Re: Re: Ruby 1.9 - Bug #407 String#<<"
on Sat, 20 Sep 2008 21:02:36 +0900, Tanaka Akira akr@fsij.org writes:

|中身が ASCII のみの文字列リテラルなら挙動も同じだったのが、
|今では挙動が変化するようになったことを指しています。

うーむ、同じファイルであればエンコーディングが同じという「わ
かりやすさ」を取るか、中身がASCIIのみであればエンコーディング
が同じというわかりやすさを取るか、という対立だと理解すればよ
いでしょうか。

=end

#11 Updated by Martin Dürst over 6 years ago

=begin
At 21:53 08/09/19, NARUSE, Yui wrote:

Yukihiro Matsumoto さんは書きました:

まつもと ゆきひろです

このチケットに関連してると思うのですが、

|> % ruby19 -Ku -ve'p "ABC" << 256'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> -e:1:in `': 256 out of char range (RangeError)
|>
|> UTF-8 だとこんな感じ。
|> % ruby19 -Ku -ve's="ABC\u3042" << 256;puts s.dump'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> "ABC\xE3\x81\x82\xC4\x80"

ここは UTF-8 なので、"ABC\u3042\u0100" の方は一般的なユーザに
取ってずっとありがたいかもしれません。

宜しくお願いします。 Martin.

#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp

=end

Also available in: Atom PDF