Bug #8652
closed
gem で rb_secure(4) を使用するとビルドエラーとなる
Added by hsbt (Hiroshi SHIBATA) almost 11 years ago.
Updated almost 11 years ago.
Description
linux で ruby-fcgi(https://github.com/saks/ruby-fcgi) という rb_secure(4) を使っている gem を trunk でコンパイルしようと失敗してしまいます。
$ make
compiling fcgi.c
(snip)
fcgi.c:231:3: エラー: call to ‘ruby$safe_level$4’ declared with attribute error: $SAFE=4 is obsolete
fcgi.c: 関数 ‘fcgi_stream_putc’ 内:
fcgi.c:219:3: エラー: call to ‘ruby$safe_level$4’ declared with attribute error: $SAFE=4 is obsolete
make: *** [fcgi.o] エラー 1
Mac OS X 10.8.4 だと上記のエラーは発生しません。
エラーが発生する linux の gcc は gcc バージョン 4.6.4 (Funtoo 4.6.4) です。
- Status changed from Open to Assigned
- Assignee changed from shugo (Shugo Maeda) to nobu (Nobuyoshi Nakada)
hsbt (Hiroshi SHIBATA) wrote:
linux で ruby-fcgi(https://github.com/saks/ruby-fcgi) という rb_secure(4) を使っている gem を trunk でコンパイルしようと失敗してしまいます。
blameしたところなかださんがr41273で変更されているようです。
個人的には、$SAFEを4以上にセットするコードはエラーにすべきですが、rb_secure(4)のようなコードはビルドできた方がよいと考えています。
shugo (Shugo Maeda) wrote:
hsbt (Hiroshi SHIBATA) wrote:
linux で ruby-fcgi(https://github.com/saks/ruby-fcgi) という rb_secure(4) を使っている gem を trunk でコンパイルしようと失敗してしまいます。
blameしたところなかださんがr41273で変更されているようです。
コンパイルエラーメッセージの通り、その意図の是非はおいておいて、意図的なものですね。
個人的には、$SAFEを4以上にセットするコードはエラーにすべきですが、rb_secure(4)のようなコードはビルドできた方がよいと考えています。
実行時にエラーでこけるより、コンパイル時にこけたほうが早く気付けて良いのではないですか?
ビルドがこけるので良い気がしています。
柴田さんがなぜコケるという事でバグレポートを上げているのか気になります。
意図的な変更だと思っていなかったのか、あるいはコケると何か問題があるという事だと思うのですが、
後者だとしたら具体的に何なのか分かると良いのかなと。
naruse (Yui NARUSE) wrote:
linux で ruby-fcgi(https://github.com/saks/ruby-fcgi) という rb_secure(4) を使っている gem を trunk でコンパイルしようと失敗してしまいます。
blameしたところなかださんがr41273で変更されているようです。
コンパイルエラーメッセージの通り、その意図の是非はおいておいて、意図的なものですね。
はい、そう思います。
個人的には、$SAFEを4以上にセットするコードはエラーにすべきですが、rb_secure(4)のようなコードはビルドできた方がよいと考えています。
実行時にエラーでこけるより、コンパイル時にこけたほうが早く気付けて良いのではないですか?
rb_secure(4)は$SAFEを4以上にセットするものではなく、$SAFEが4以上にセットされている時にSecurityErrorを発生されるものです。
おおざっぱに言えば、rb_secure(4)はif $SAFE >= 4; raise SecurityError; endのような意味です。¶
trunkでは$SAFEを4以上にセットできないので、rb_secure(4)で実行時に例外が発生することはないはずですが、何か勘違いしているでしょうか。
rb_secure(4)が残っていてもごくわずかなオーバーヘッドがあるだけで実害はないと思いますので、サードパーティの拡張ライブラリのことも考えると、互換性のためにコンパイルエラーとしない方がよいと考えています。
sorah (Shota Fukumori) wrote:
ビルドがこけるので良い気がしています。
なぜこけた方がよいと思いますか?
なぜこけた方がよいと思いますか?
なるせさんと同じ理由でしたが、rb_secure の挙動がそれなら(勘違いでした)エラーにならない方が良いと思えてきました。
shugo (Shugo Maeda) wrote:
naruse (Yui NARUSE) wrote:
個人的には、$SAFEを4以上にセットするコードはエラーにすべきですが、rb_secure(4)のようなコードはビルドできた方がよいと考えています。
実行時にエラーでこけるより、コンパイル時にこけたほうが早く気付けて良いのではないですか?
rb_secure(4)は$SAFEを4以上にセットするものではなく、$SAFEが4以上にセットされている時にSecurityErrorを発生されるものです。
おおざっぱに言えば、rb_secure(4)はif $SAFE >= 4; raise SecurityError; endのような意味です。¶
trunkでは$SAFEを4以上にセットできないので、rb_secure(4)で実行時に例外が発生することはないはずですが、何か勘違いしているでしょうか。
rb_secure(4)が残っていてもごくわずかなオーバーヘッドがあるだけで実害はないと思いますので、サードパーティの拡張ライブラリのことも考えると、互換性のためにコンパイルエラーとしない方がよいと考えています。
おぉ、仰るとおり混同していました。
- rb_set_safe_level() がコンパイル時にエラーになるのはそのまま
- rb_secure(4) はコンパイル時にはエラーにしない → 事実上何もしない
とするべき、という話ですね。
んー、わたしは間とって rb_secure(4) にコンパイル時 warning 派かなぁ。
naruse (Yui NARUSE) wrote:
rb_secure(4)は$SAFEを4以上にセットするものではなく、$SAFEが4以上にセットされている時にSecurityErrorを発生されるものです。
おおざっぱに言えば、rb_secure(4)はif $SAFE >= 4; raise SecurityError; endのような意味です。¶
trunkでは$SAFEを4以上にセットできないので、rb_secure(4)で実行時に例外が発生することはないはずですが、何か勘違いしているでしょうか。
rb_secure(4)が残っていてもごくわずかなオーバーヘッドがあるだけで実害はないと思いますので、サードパーティの拡張ライブラリのことも考えると、互換性のためにコンパイルエラーとしない方がよいと考えています。
おぉ、仰るとおり混同していました。
了解です。
- rb_set_safe_level() がコンパイル時にエラーになるのはそのまま
- rb_secure(4) はコンパイル時にはエラーにしない → 事実上何もしない
とするべき、という話ですね。
んー、わたしは間とって rb_secure(4) にコンパイル時 warning 派かなぁ。
はい、警告あたりが妥当だと思います。
どうでしょうか? > なかださん
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
This issue was solved with changeset r42037.
Hiroshi, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
ruby.h: error only in the core
- include/ruby/ruby.h (RUBY_SAFE_LEVEL_CHECK): make only
rb_set_safe_level(4) an error always but make rb_secure(4) an error
only in the core. [ruby-dev:47517] [Bug #8652]
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0
Updated by 
Updated by 
Updated by 
Updated by