ruby-trunk-changes r33750 - r33761

NUM2LONG などの整数の変換マクロの実装がリファクタリングされています。

kosaki:r33750 2011-11-15 01:00:29 +0900

NUM2SHORT(), NUM2USHORT() の追加について NEWS ファイルに追記しています。

svn:r33751 2011-11-15 01:00:33 +0900

version.h の日付更新。

ayumin:r33752 2011-11-15 01:10:17 +0900

IO#fcntl のテストが Mac OS X ShowLeopard でエラーになっていたので Tempfile.open を Tempfile.new にしているのですが、Tempfile.new がブロックを yield してくれないのでテストがスキップされています。

ayumin:r33753 2011-11-15 02:02:10 +0900

というわけで、エラーになっていたのは F_DUPFD で指定する fd の番号が大きすぎたためなので 500 -> 255 に小くしています。 [ruby-dev:44866]

naruse:r33754 2011-11-15 09:51:46 +0900

正規表現エンジンのデバッグ用の表示ルーチンで出力が重複していたのを修正。 [ruby-core:40964]

kosaki:r33755 2011-11-15 10:41:58 +0900

fcntl(F_DUPFD) のテストで更に OpenBSD では fd の制限がもっと小さいそうなので 63 まで減らしています。 [ruby-dev:44872]

kosaki:r33756 2011-11-15 13:18:43 +0900

include/ruby/ruby.h の NUM2LONG(), NUM2INT(), etc... の定義を __GNUC__ が定義されている時は gcc の拡張を利用してマクロで記述していたのをやめて、常にインライン関数として定義するようにしています。 gcc 向けの実装が特に早いコードを吐いているわけじゃないということと、インライン関数だとデバッガで追いやすいということです。もうひとつ ABI compatibility のためというコメントがあるのですが、これはどういうことかなぁ。マクロだと結局拡張ライブラリ等には埋め込まれてしまうからマクロから呼ぶ関数に依存してしまうということかなと思ったのですが、それはインライン関数でも同じですよね。

ngoto:r33757 2011-11-15 13:42:31 +0900

Sun Sparc 向けの register windows 退避のためのアセンブリコードを sparc.c という独立したファイルに移動しています。なんでも同じファイルで定義されていて inline に展開されるとうまく動作しなかったとのこと。inline 展開されて更に reorder されてしまったりするんでしょうか。 [ruby-core:40685] [Bug #5244]

ngoto:r33758 2011-11-15 14:05:35 +0900

r33757 の関数の宣言、定義のスタイル修正。

kosaki:r33759 2011-11-15 14:57:34 +0900

r33756 の ChangeLog の 3つ目のコメントは削除されていて、NUM2LONG() などは対応する inline 関数を呼ぶマクロに変更されています。

nobu:r33760 2011-11-15 16:04:08 +0900

新規追加ファイルの svn:property 変更。

akr:r33761 2011-11-15 20:09:47 +0900

Linux プラットフォームを識別するために defined(linux) や defined(__linux) などを利用しているところを defined(__linux__) に統一するようにしています。