[#14922] alias $gvar — Koji Arai <JCA02266@...>

新井です。

19 messages 2001/10/14

[#15006] Re: eval.c (rb_stack_check): prohibit recursive raising error — WATANABE Hirofumi <eban@...>

わたなべです。

13 messages 2001/10/26
[#15008] Re: eval.c (rb_stack_check): prohibit recursive raising error — Shugo Maeda <shugo@...> 2001/10/26

前田です。

[ruby-dev:14852] Re: custom marshal

From: matz@... (Yukihiro Matsumoto)
Date: 2001-10-03 03:40:59 UTC
List: ruby-dev #14852
まつもと ゆきひろです

In message "[ruby-dev:14848] Re: custom marshal"
    on 01/10/03, nobu.nakada@nifty.ne.jp <nobu.nakada@nifty.ne.jp> writes:

|>   * allocation frameworkの追加
|> 
|>     オブジェクトの割り当てを各クラスのallocateメソッドによっ
|>     て行うようにRuby全体を変更し、TYPE_UCLASSに対して、もう
|>     ひとつ別のオブジェクトをallocateし、そのオブジェクトと
|>     r_object()の結果のTYPEが一致するかを確認する、という方法
|>     でより厳密なチェックを行います。
|
| これは今まで何度か話に上がってるbasicNewのようなもの? あとは
|拡張ライブラリへの影響はどの程度でしょうか。

そうです。拡張ライブラリについては今までのやり方でT_OBJECT以
外のインスタンスを割り当てるクラスを定義しているものはloadで
きません。でも、一番使われてそうなT_DATAはそもそもdumpできな
いのであまり問題はないのでは?

でも、become対策だけなら最初のT_OBJECTのチェックだけで十分で
はないかという気がしてきました。というのも、

  * 問題があるのはスーパークラスとサブクラスでTYPEが違う場合
    だけ

  * そのようなケースは(すくなくとも現状では)T_OBJECTと別の
    TYPEという組み合わせしか存在しない

  * そうでないケースを実現するためにはわざわざそのための拡張
    モジュールが必要で、拡張モジュールを使えばもともと落とす
    のは簡単なのだから、対応する意味はない

からです。どうなんでしょうね。いや、allocation frameworkはい
ずれにせよ導入しますが。

                                まつもと ゆきひろ /:|)

In This Thread