[#36672] [Bug #616] instance_eval and Module#to_s — Shyouhei Urabe <redmine@...>

Bug #616: instance_eval and Module#to_s

12 messages 2008/10/06

[#36750] [Bug #650] Marshal.load raises RegexpError — Shyouhei Urabe <redmine@...>

Bug #650: Marshal.load raises RegexpError

30 messages 2008/10/15
[#36769] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/17

まつもと ゆきひろです

[#36771] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/17

卜部です。

[#36772] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/17

まつもと ゆきひろです

[#36773] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/17

卜部です。

[#36784] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/18

まつもと ゆきひろです

[#36785] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/18

卜部です。

[#36793] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/19

まつもと ゆきひろです

[#36794] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/19

Yukihiro Matsumoto さんは書きました:

[#36823] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/21

まつもと ゆきひろです

[#36830] Re: [Bug #650] Marshal.load raises RegexpError — Urabe Shyouhei <shyouhei@...> 2008/10/21

もとの正規表現にバグがあるのは認めますが、それに巻き込まれてでかいPStore

[#36833] Re: [Bug #650] Marshal.load raises RegexpError — Yukihiro Matsumoto <matz@...> 2008/10/21

まつもと ゆきひろです

[#36764] Re: [ruby-cvs:27036] Ruby:r19818 (trunk): * transcode.c (str_transcode0): String#encode without argument now — Martin Duerst <duerst@...>

まつもとさん、こんばんは。

11 messages 2008/10/17
[#36767] Re: [ruby-cvs:27036] Ruby:r19818 (trunk): * transcode.c (str_transcode0): String#encode without argument now — Yukihiro Matsumoto <matz@...> 2008/10/17

まつもと ゆきひろです

[#36799] Re: [ruby-cvs:27036] Ruby:r19818 (trunk): * transcode.c (str_transcode0): String#encode without argument now — Martin Duerst <duerst@...> 2008/10/20

まつもとさん、こんにちは。

[#36774] ConverterNotFoundError while making Ruby in Windows(trunk) — Masaki Suketa <masaki.suketa@...>

助田です。

13 messages 2008/10/17
[#36797] Re: ConverterNotFoundError while making Ruby in Windows(trunk) — "U.Nakamura" <usa@...> 2008/10/20

こんにちは、なかむら(う)です。

[#36800] Re: ConverterNotFoundError while making Ruby in Windows(trunk) — "U.Nakamura" <usa@...> 2008/10/20

こんにちは、なかむら(う)です。

[#36789] [Bug #660] 数字を3桁ずつコンマで区切るsprintf書式指定 — "rubikitch ." <redmine@...>

Bug #660: 数字を3桁ずつコンマで区切るsprintf書式指定

13 messages 2008/10/19

[#37007] [Bug:1.9] 1+1+1+...+1 dumps core — "Yusuke ENDOH" <mame@...>

遠藤です。

13 messages 2008/10/31

[ruby-dev:36917] VMまわりのシンボルにも「rb_」を付けてほしい

From: Tadashi Saito <shiba@...2.accsnet.ne.jp>
Date: 2008-10-24 18:30:27 UTC
List: ruby-dev #36917
斎藤と申します。連投ですみません。

さて、rb_等のprefixが付いていないシンボルに対して何らかの措置をとるパッチを
一通り投げました。それらは以下のようにしてチェックしたものです。

$ nm -gD libruby-trunk.so|grep -v ' U '|
> egrep -iv ' (rb|ruby|Init|onig|st|_)'| awk '{print $3}'

この中でdln_*とnode*は何か理由がある、と聞いたので放置しておくとすると、
残りはYARVで導入されたもののようです。それらを以下に挙げます。

insn_make_insn_table
insns_name_array
iseq_build_from_ary
iseq_compile
iseq_load
iseq_translate_threaded_code
vm_collect_local_variables_in_heap
vm_cref
vm_debug_print_post
vm_debug_print_pre
vm_debug_print_register
vm_env_dump_raw
vm_get_insns_address_table
vm_get_ruby_level_caller_cfp
vm_get_ruby_level_next_cfp
vm_get_sourceline
vm_invoke_proc
vm_jump_tag_but_local_jump
vm_localjump_error
vm_make_env_object
vm_make_jump_tag_but_local_jump
vm_make_proc
vm_proc_dump_raw
vm_stack_dump_each
vm_stack_dump_raw
vm_stack_dump_raw_current
vm_stack_dump_th
vm_stack_to_heap
vm_thread_dump_regs
vm_thread_dump_state

これらにも rb_ を付けていただけないでしょうか。

以前ささださんにお会いした時、少しお話ししたのですが、これらは外部で利用して
ほしくないために、意図的に rb_ を省いているということでした。

しかし、「外部から使われたくない」ことと、rb_ がない(これまでの規約に反する)
ことで「名前がかぶる」という可能性は、分けて考える必要があるのではないで
しょうか。

たとえば皆さんご存知のとおり、VMという言葉は言語処理系に限らず、様々なレベルで
使われる言葉です。よってvm_というprefixだけだと、どんなVMか分かりません。
RubyVMを組み込んだ他の種類のVMが実装されれば、当然vm_というprefixが使われる
可能性があるでしょう。もっと言えば、Virtual Machineかどうかさえ分かりません。

そういった可能性を考えず rb_ を省くのはあまりうれしくない、と自分は考えます。
「これはRubyである」というrb_ prefixを付けた上でならば、名前がぶつかれば
「rb_はRubyで使われるから避けてね」と説明できるでしょうし、C APIの作者からも
わかりやすくなると思います。

それで、外部からの利用を意図しているAPIと区別がつかずに困る、というのであれば、
それはドキュメントで明示するのが本筋ではないかと思うのですが、どうでしょうか。


以下、単なるアイデアの羅列ですが:

もしシンボル名だけで、APIとして利用できる・して欲しくないの区別をつけるならば、
「rb_」の前に「_」を付けて「_rb_foo()」にする、というのはどうでしょうか。
いかにも触りたくない感じになります。

もう一つ、librubyの外からは見えないが、.cの間では見える、という設定法があります。
GNU拡張になりますが、 __attribute__((visibility("hidden"))) というのを
設定すると、外部からは見えなくなるそうです。(これは Binary Hacks #29の
受け売りです...)
この方法の問題は、GCC3以降しか使えないという点です。GCC 2.xやMS Cでは見えて
しまう(と思う)ので、環境によって見えたり見えなかったりするシンボルができる、
ということになります。

もっとも、上記二つのアイデアを合わせればもっとそれらしくなるかもしれません。
つまり、使って欲しくない関数はGCC3以降では見えず、その他のコンパイラで
コンパイルした場合でも _rb_ 接頭辞によって、「使ってほしくない」という
メッセージが送れる、といった具合です。

羅列終わり。


今のところこのメールで触れた以外には、prefixを付けて回る必要はなさそうです。
つい先ほど作業を始めましたが、去年よりもだいぶ減っていたので非常に助かりました。
意識してコミットしていただき、本当にありがとうございました。

ーー
斎藤ただし

In This Thread

Prev Next