[#45311] 開発会議 — SASADA Koichi <ko1@...>
笹田です．
10 messages
2012/03/06
[#45312] Re: 開発会議
— "ayumu.aizawa@..." <ayumu.aizawa@...>
2012/03/06
US=1B$B$K$$$k$N$G!"=1B(BSkype=1B$B$H$+=1B(BFaceTime=1B$B$G;22C$7$?$$$G$9!#=1B=
[#45341] 非同期割り込みに対する対処案（日本語版） — SASADA Koichi <ko1@...>
ささだです．
28 messages
2012/03/11
[#45816] Re: 非同期割り込みに対する対処案（日本語版）
— SASADA Koichi <ko1@...>
2012/06/25
ささだです．
[#45817] Re: 非同期割り込みに対する対処案（日本語版）
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 18:26 SASADA Koichi <[email protected]>:
[#45819] Re: 非同期割り込みに対する対処案（日本語版）
— SASADA Koichi <ko1@...>
2012/06/25
ささだです．
[#45820] Re: 非同期割り込みに対する対処案（日本語版）
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 19:39 SASADA Koichi <[email protected]>:
[#45827] Re: 非同期割り込みに対する対処案（日本語版）
— SASADA Koichi <ko1@...>
2012/06/25
(2012/06/25 20:32), Tanaka Akira wrote:
[#45835] Re: 非同期割り込みに対する対処案（日本語版）
— KOSAKI Motohiro <kosaki.motohiro@...>
2012/06/25
> の３つになるような気がしていますので，ある例外がこれら 3 つのどの状態に
[#45841] Re: 非同期割り込みに対する対処案（日本語版）
— Tanaka Akira <akr@...>
2012/06/25
2012年6月26日 3:40 SASADA Koichi <[email protected]>:
[#45844] Re: 非同期割り込みに対する対処案（日本語版）
— SASADA Koichi <ko1@...>
2012/06/25
(2012/06/26 5:07), Tanaka Akira wrote:
[#45871] Re: 非同期割り込みに対する対処案（日本語版）
— Tanaka Akira <akr@...>
2012/06/29
2012年6月26日 5:15 SASADA Koichi <[email protected]>:
[#45372] Marshal.dumpにおけるインスタンス変数の取り扱いについて — keiju@... (Keiju ISHITSUKA)
けいじゅ＠いしつかです.
14 messages
2012/03/16
[#45376] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— Yukihiro Matsumoto <matz@...>
2012/03/17
まつもと ゆきひろです
[#45377] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— keiju@... (石塚圭樹)
2012/03/17
けいじゅ＠いしつかです.
[#45381] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— Yukihiro Matsumoto <matz@...>
2012/03/17
まつもと ゆきひろです
[#45399] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— keiju@... (石塚圭樹)
2012/03/18
けいじゅ＠いしつかです.
[#45401] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— Tanaka Akira <akr@...>
2012/03/19
2012年3月19日5:54 石塚圭樹 <[email protected]>:
[#45405] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— keiju@... (石塚圭樹)
2012/03/19
けいじゅ＠いしつかです.
[#45451] [ruby-trunk - Feature #6218][Open] struct.cのrb_struct_s_members_m()について — "Glass_saga (Masaki Matsushita)" <glass.saga@...>
6 messages
2012/03/28
[ruby-dev:45425] [ruby-trunk - Bug #6145][Closed] two possible bugs in Onigmo
From:
"naruse (Yui NARUSE)" <naruse@...>
Date:
2012-03-22 00:20:53 UTC
List:
ruby-dev #45425
Issue #6145 has been updated by naruse (Yui NARUSE).
Status changed from Assigned to Closed
----------------------------------------
Bug #6145: two possible bugs in Onigmo
https://bugs.ruby-lang.org/issues/6145#change-25029
Author: mame (Yusuke Endoh)
Status: Closed
Priority: Normal
Assignee: naruse (Yui NARUSE)
Category:
Target version:
ruby -v: ruby 2.0.0dev (2012-03-14 trunk 35017) [i686-linux]
naruse さん、k-takata さん
遠藤です。
Coverity Scan さんが見つけてくれたバグの可能性 2 つです。
(ただし false positive の可能性は高い)
1 つめ。regcomp.c の compile_length_enclose_node という関数で
1222 if (node->target) {
1223 tlen = compile_length_tree(node->target, reg);
1224 if (tlen < 0) return tlen;
1225 }
1226 else
1227 tlen = 0;
というように、node->target が NULL の可能性を考慮しているくせに、
その後で
1269 case ENCLOSE_CONDITION:
1270 len = SIZE_OP_CONDITION;
1271 if (NTYPE(node->target) == NT_ALT) {
と、node->target を遠慮なくデリファレンスしていて、まずいんじゃ
ないの？とのことです。
実際に ENCLOSE_CONDITION のケースで node->target が NULL になる
ことはないのかな？と思いましたが、確認お願いします。
安全な場合でも NULL check を入れてくれると、coverity scan さんの
alert が減って嬉しいです。(必須ではありません)
2 つめ。regparse.c に以下のようなコードがあります。
5974 *np = node_new_cclass();
5975 CHECK_NULL_RETURN_MEMERR(*np);
5976 cc = NCCLASS(*np);
5977 add_ctype_to_cc(cc, tok->u.prop.ctype, 0, 0, env);
5978 if (tok->u.prop.not != 0) NCCLASS_SET_NOT(cc);
5979 #ifdef USE_SHARED_CCLASS_TABLE
5980 }
5977 行目の add_ctype_to_cc の返り値をチェックしてません。
他の add_ctype_to_cc の呼び出しではことごとく返り値チェックして
いるので、ここだけ忘れてんじゃないの？いいの？とのことです。
実際に add_ctype_to_cc の返り値が 0 以外になるケースがあるのかは
わかりませんでしたが、まあチェックしてあげるといい気がします。
--
Yusuke Endoh <[email protected]>
--
http://bugs.ruby-lang.org/