From kondo.hideaki ＠ oss.ntt.co.jp Tue Dec 9 11:28:59 2008 From: kondo.hideaki ＠ oss.ntt.co.jp (Hideaki Kondo) Date: Tue, 09 Dec 2008 11:28:59 +0900 Subject: [Ultramonkey-l7-develop 227] Re: =?iso-2022-jp?b?VU0tTDcgGyRCJSIlLyU7JTklbSUwPVBOTz1oTX0bKEI=?= =?iso-2022-jp?b?GyRCREkyQyRLJEQkJCRGGyhC?= In-Reply-To: References: <20081208163732.D984.KONDO.HIDEAKI@oss.ntt.co.jp> Message-ID: <20081209110009.D99C.KONDO.HIDEAKI@oss.ntt.co.jp> 竹林さん、各位 近藤です。 お疲れ様です。 コメント有難うございます。 > glibc 内の inet_ntoa() の実装ではバッファサイズは 18 バイトになりますが， > この点の考慮は要らないでしょうか． > > xxx.xxx.xxx.xxx なので，16 バイトあれば充分と言えば充分ですが・・・ (snip) > ・・・何故 inet_ntoa のバッファサイズが 18 バイトなんでしょうね． ★ 少し調べてみましたが、例えばFreeBSDにおける実装では、 「sizeof("aaa.bbb.ccc.ddd")」(つまり16)となっていたり、 ------------------------------------------------------------------ http://fxr.watson.org/fxr/source/libkern/inet_ntoa.c?v=DFBSD static char buf[sizeof "aaa.bbb.ccc.ddd"]; ------------------------------------------------------------------ WINAPIの実装では、以下のようになっていたりしますね。 ------------------------------------------------------------------ http://research.microsoft.com/projects/invisible/src/winshim/inet_ntoa.c.htm static char b[18]; /* perfectly MP safe Berkeley junk, tzk tzk */ ------------------------------------------------------------------ 上記の"perfectly MP safe Berkeley junk"というコメントから 特別な理由があったということではなく、そのまま過去の実装を 踏襲した?結果のように思われます。 Linuxにおけるinet_ntoa()の実装に変更がない限り、（静的に割当 られた領域から逸脱してデータを読み出すようなことをすれば確かに 問題ですが）この領域の範囲内で必要となるIPアドレス文字列数分( sizeof("aaa.bbb.ccc.ddd"))を指定して読み出すことになるだけ ですので、18バイトまでの考慮は不要で16バイトのままで良いと考えます。 もちろん、今後IPv6対応化等において別途考慮は必要になりますが。。。 特に異論等なければ、このままとさせていただきます。 On Mon, 08 Dec 2008 18:54:52 +0900 Shinya TAKEBAYASHI wrote: > 竹林です． > お疲れ様です． > > > > メモリ領域に変換後のIPアドレスは生成されることから、以下のように > > strlen()+1は使わずにADDR_STR_LEN(=16)を埋め込みで良いですね。 > > glibc 内の inet_ntoa() の実装ではバッファサイズは 18 バイトになりますが， > この点の考慮は要らないでしょうか． > > xxx.xxx.xxx.xxx なので，16 バイトあれば充分と言えば充分ですが・・・ > > > -- inet_ntoa.c > > static char local_buf[18]; > > ・・・ snip ・・・ > > __snprintf (buffer, 18, "%d.%d.%d.%d", > bytes[0], bytes[1], bytes[2], bytes[3]); > > > > ・・・何故 inet_ntoa のバッファサイズが 18 バイトなんでしょうね． > > ----------------------------------------------------------- > Shinya TAKEBAYASHI > > E-mail: takebayashi.shinya ＠ oss.ntt.co.jp > GPG ID: 395EFCE8 > GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 > ----------------------------------------------------------- > > > Hideaki Kondo wrote in message <20081208163732.D984.KONDO.HIDEAKI ＠ oss.ntt.co.jp > > > *** Subject: [Ultramonkey-l7-develop 223] Re: UM-L7 アクセスログ出力処理追加につ > いて > *** Date: 2008/12/08 17:00:48 > > > > UM-L7開発者各位 > > > > 近藤です。 > > お疲れ様です。 > > > > 先のメールに関連して一点補足です。 > > > > > /*-------- INFO LOG (Access Log) --------*/ > > > char addr_str_tmp[ADDR_STR_LEN] = {0}; > > > memcpy(addr_str_tmp, inet_ntoa(conn->caddr.sin_addr), strlen(inet_ntoa(conn- > >caddr.sin_addr))+1); > > > LOGGER_PUT_LOG_INFO(LOG_CAT_L7VSD_NETWORK,342, > > > "[[AccessLog] (SRC)%s:%d --> (DST)%s:%d ]", > > > addr_str_tmp, > > > ntohs(conn->caddr.sin_port), > > > inet_ntoa(conn->dest->addr.sin_addr), > > > ntohs(conn->dest->addr.sin_port)); > > > /*------ INFO LOG END (Access Log) ------*/ > > > > > > アクセスログ出力に処理については、上記の通りコーディング > > しておりますが、先に触れましたinet_ntoa()関数の仕様を考えると、 > > memcpy()の引数でわざわざstrlen()を呼び出す必要はないですね。 > > > > memcpy時にアドレス例外発生を懸念してstrlen()を呼び出して > > 文字列数を得るようにしておりましたが、静的に割り当てられている > > メモリ領域に変換後のIPアドレスは生成されることから、以下のように > > strlen()+1は使わずにADDR_STR_LEN(=16)を埋め込みで良いですね。 > > > > memcpy(addr_str_tmp, inet_ntoa(conn->caddr.sin_addr), ADDR_STR_LEN); > > > > INFOログレベルチェックを入れるかどうかは、皆さんのご意見等を待つ > > として、少しでも処理を軽くするために呼び出し関数は減らしたいですので > > 特に異論等なければ、上記のように修正させて頂きたいと思います。 > > > > 念のため、ざっと動作確認してみましたが、特に問題等は発生しておりません。 > > > > 以上よろしくお願い致します。 > > -- Hideaki Kondo From makoto ＠ kanon-net.jp Tue Dec 9 13:05:59 2008 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Tue, 09 Dec 2008 13:05:59 +0900 Subject: [Ultramonkey-l7-develop 228] Re: =?iso-2022-jp?b?VU0tTDcgGyRCJSIlLyU7JTklbSUwPVBOTz1oTX0bKEI=?= =?iso-2022-jp?b?GyRCREkyQyRLJEQkJCRGGyhC?= In-Reply-To: <20081209110009.D99C.KONDO.HIDEAKI@oss.ntt.co.jp> References: <20081208163732.D984.KONDO.HIDEAKI@oss.ntt.co.jp> <20081209110009.D99C.KONDO.HIDEAKI@oss.ntt.co.jp> Message-ID: 近藤 様 竹林です． お疲れ様です． 下記承知しました． 調査ありがとうございます． 先ほど口頭でもお話ししましたが，最終版のパッチを頂けますか． 竹林が branch へマージします． ---------------------------------------------------------------- Shinya TAKEBAYASHI E-mail : makoto ＠ kanon-net.jp GPG ID : FFD20D1F GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ---------------------------------------------------------------- Hideaki Kondo wrote in message <20081209110009.D99C.KONDO.HIDEAKI ＠ oss.ntt.co.jp > *** Subject: [Ultramonkey-l7-develop 227] Re: UM-L7 アクセスログ出力処理追加につ いて *** Date: 2008/12/09 11:28:59 > > 竹林さん、各位 > > 近藤です。 > お疲れ様です。 > > コメント有難うございます。 > > > glibc 内の inet_ntoa() の実装ではバッファサイズは 18 バイトになりますが， > > この点の考慮は要らないでしょうか． > > > > xxx.xxx.xxx.xxx なので，16 バイトあれば充分と言えば充分ですが・・・ > (snip) > > ・・・何故 inet_ntoa のバッファサイズが 18 バイトなんでしょうね． > > ★ > 少し調べてみましたが、例えばFreeBSDにおける実装では、 > 「sizeof("aaa.bbb.ccc.ddd")」(つまり16)となっていたり、 > > ------------------------------------------------------------------ > http://fxr.watson.org/fxr/source/libkern/inet_ntoa.c?v=DFBSD > > static char buf[sizeof "aaa.bbb.ccc.ddd"]; > ------------------------------------------------------------------ > > WINAPIの実装では、以下のようになっていたりしますね。 > > ------------------------------------------------------------------ > http://research.microsoft.com/projects/invisible/src/winshim/inet_ntoa.c.htm > > static char b[18]; /* perfectly MP safe Berkeley junk, tzk tzk */ > ------------------------------------------------------------------ > > 上記の"perfectly MP safe Berkeley junk"というコメントから > 特別な理由があったということではなく、そのまま過去の実装を > 踏襲した?結果のように思われます。 > > Linuxにおけるinet_ntoa()の実装に変更がない限り、（静的に割当 > られた領域から逸脱してデータを読み出すようなことをすれば確かに > 問題ですが）この領域の範囲内で必要となるIPアドレス文字列数分( > sizeof("aaa.bbb.ccc.ddd"))を指定して読み出すことになるだけ > ですので、18バイトまでの考慮は不要で16バイトのままで良いと考えます。 > > もちろん、今後IPv6対応化等において別途考慮は必要になりますが。。。 > > 特に異論等なければ、このままとさせていただきます。 > From kondo.hideaki ＠ oss.ntt.co.jp Tue Dec 9 13:34:58 2008 From: kondo.hideaki ＠ oss.ntt.co.jp (Hideaki Kondo) Date: Tue, 09 Dec 2008 13:34:58 +0900 Subject: [Ultramonkey-l7-develop 229] Re: =?iso-2022-jp?b?VU0tTDcgGyRCJSIlLyU7JTklbSUwPVBOTz1oTX0bKEI=?= =?iso-2022-jp?b?GyRCREkyQyRLJEQkJCRGGyhC?= In-Reply-To: References: <20081209110009.D99C.KONDO.HIDEAKI@oss.ntt.co.jp> Message-ID: <20081209132151.D99F.KONDO.HIDEAKI@oss.ntt.co.jp> 竹林さま、各位 近藤です。 お疲れ様です。 ご対応有難うございます。 ログレベルチェックを考慮した最終版パッチを 作成しましたので、送付させていただきます。 カレントログレベルチェックを行い、INFOレベル以下（ つまり、INFO または DEBUGレベルが対象）であれば、 アクセスログを出力する実装となっております。 ご確認の程よろしくお願い致します。 お手数をおかけしますが、branchへのマージを よろしくお願い致します。＞竹林さん On Tue, 09 Dec 2008 13:05:59 +0900 Shinya TAKEBAYASHI wrote: > 近藤 様 > > > 竹林です． > お疲れ様です． > > 下記承知しました． > 調査ありがとうございます． > > 先ほど口頭でもお話ししましたが，最終版のパッチを頂けますか． > 竹林が branch へマージします． > > ---------------------------------------------------------------- > Shinya TAKEBAYASHI > > E-mail : makoto ＠ kanon-net.jp > GPG ID : FFD20D1F > GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F > ---------------------------------------------------------------- > > Hideaki Kondo wrote in message <20081209110009.D99C.KONDO.HIDEAKI ＠ oss.ntt.co.jp > > > *** Subject: [Ultramonkey-l7-develop 227] Re: UM-L7 アクセスログ出力処理追加につ > いて > *** Date: 2008/12/09 11:28:59 > > > > 竹林さん、各位 > > > > 近藤です。 > > お疲れ様です。 > > > > コメント有難うございます。 > > > > > glibc 内の inet_ntoa() の実装ではバッファサイズは 18 バイトになりますが， > > > この点の考慮は要らないでしょうか． > > > > > > xxx.xxx.xxx.xxx なので，16 バイトあれば充分と言えば充分ですが・・・ > > (snip) > > > ・・・何故 inet_ntoa のバッファサイズが 18 バイトなんでしょうね． > > > > ★ > > 少し調べてみましたが、例えばFreeBSDにおける実装では、 > > 「sizeof("aaa.bbb.ccc.ddd")」(つまり16)となっていたり、 > > > > ------------------------------------------------------------------ > > http://fxr.watson.org/fxr/source/libkern/inet_ntoa.c?v=DFBSD > > > > static char buf[sizeof "aaa.bbb.ccc.ddd"]; > > ------------------------------------------------------------------ > > > > WINAPIの実装では、以下のようになっていたりしますね。 > > > > ------------------------------------------------------------------ > > http://research.microsoft.com/projects/invisible/src/winshim/inet_ntoa.c.htm > > > > static char b[18]; /* perfectly MP safe Berkeley junk, tzk tzk */ > > ------------------------------------------------------------------ > > > > 上記の"perfectly MP safe Berkeley junk"というコメントから > > 特別な理由があったということではなく、そのまま過去の実装を > > 踏襲した?結果のように思われます。 > > > > Linuxにおけるinet_ntoa()の実装に変更がない限り、（静的に割当 > > られた領域から逸脱してデータを読み出すようなことをすれば確かに > > 問題ですが）この領域の範囲内で必要となるIPアドレス文字列数分( > > sizeof("aaa.bbb.ccc.ddd"))を指定して読み出すことになるだけ > > ですので、18バイトまでの考慮は不要で16バイトのままで良いと考えます。 > > > > もちろん、今後IPv6対応化等において別途考慮は必要になりますが。。。 > > > > 特に異論等なければ、このままとさせていただきます。 > > -- Hideaki Kondo -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: accesslog_addition_fix.patch.gz 型: application/octet-stream サイズ: 738 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/ultramonkey-l7-develop/attachments/20081209/c42705ab/attachment.obj From kondo.hideaki ＠ oss.ntt.co.jp Tue Dec 9 14:44:57 2008 From: kondo.hideaki ＠ oss.ntt.co.jp (Hideaki Kondo) Date: Tue, 09 Dec 2008 14:44:57 +0900 Subject: [Ultramonkey-l7-develop 230] Re: =?iso-2022-jp?b?VU0tTDcgGyRCJSIlLyU7JTklbSUwPVBOTz1oTX0bKEI=?= =?iso-2022-jp?b?GyRCREkyQyRLJEQkJCRGGyhC?= In-Reply-To: <20081209132151.D99F.KONDO.HIDEAKI@oss.ntt.co.jp> References: <20081209132151.D99F.KONDO.HIDEAKI@oss.ntt.co.jp> Message-ID: <20081209144130.D9A2.KONDO.HIDEAKI@oss.ntt.co.jp> 竹林さん、各位 近藤です お疲れ様です。 先に送付のパッチは、安定版Ver.2.0.0-1リリース ソースに対するパッチファイルになっておりましたので、 unstable/sachielに対するパッチを作成しましたので 再送付させていただきます。 ご確認およびご対応の程よろしくお願い致します。 On Tue, 09 Dec 2008 13:34:58 +0900 Hideaki Kondo wrote: > > 竹林さま、各位 > > 近藤です。 > お疲れ様です。 > > ご対応有難うございます。 > ログレベルチェックを考慮した最終版パッチを > 作成しましたので、送付させていただきます。 > > カレントログレベルチェックを行い、INFOレベル以下（ > つまり、INFO または DEBUGレベルが対象）であれば、 > アクセスログを出力する実装となっております。 > > ご確認の程よろしくお願い致します。 > > お手数をおかけしますが、branchへのマージを > よろしくお願い致します。＞竹林さん > > > On Tue, 09 Dec 2008 13:05:59 +0900 > Shinya TAKEBAYASHI wrote: > > > 近藤 様 > > > > > > 竹林です． > > お疲れ様です． > > > > 下記承知しました． > > 調査ありがとうございます． > > > > 先ほど口頭でもお話ししましたが，最終版のパッチを頂けますか． > > 竹林が branch へマージします． > > > > ---------------------------------------------------------------- > > Shinya TAKEBAYASHI > > > > E-mail : makoto ＠ kanon-net.jp > > GPG ID : FFD20D1F > > GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F > > ---------------------------------------------------------------- > > > > Hideaki Kondo wrote in message <20081209110009.D99C.KONDO.HIDEAKI ＠ oss.ntt.co.jp > > > > > *** Subject: [Ultramonkey-l7-develop 227] Re: UM-L7 アクセスログ出力処理追加につ > > いて > > *** Date: 2008/12/09 11:28:59 > > > > > > 竹林さん、各位 > > > > > > 近藤です。 > > > お疲れ様です。 > > > > > > コメント有難うございます。 > > > > > > > glibc 内の inet_ntoa() の実装ではバッファサイズは 18 バイトになりますが， > > > > この点の考慮は要らないでしょうか． > > > > > > > > xxx.xxx.xxx.xxx なので，16 バイトあれば充分と言えば充分ですが・・・ > > > (snip) > > > > ・・・何故 inet_ntoa のバッファサイズが 18 バイトなんでしょうね． > > > > > > ★ > > > 少し調べてみましたが、例えばFreeBSDにおける実装では、 > > > 「sizeof("aaa.bbb.ccc.ddd")」(つまり16)となっていたり、 > > > > > > ------------------------------------------------------------------ > > > http://fxr.watson.org/fxr/source/libkern/inet_ntoa.c?v=DFBSD > > > > > > static char buf[sizeof "aaa.bbb.ccc.ddd"]; > > > ------------------------------------------------------------------ > > > > > > WINAPIの実装では、以下のようになっていたりしますね。 > > > > > > ------------------------------------------------------------------ > > > http://research.microsoft.com/projects/invisible/src/winshim/inet_ntoa.c.htm > > > > > > static char b[18]; /* perfectly MP safe Berkeley junk, tzk tzk */ > > > ------------------------------------------------------------------ > > > > > > 上記の"perfectly MP safe Berkeley junk"というコメントから > > > 特別な理由があったということではなく、そのまま過去の実装を > > > 踏襲した?結果のように思われます。 > > > > > > Linuxにおけるinet_ntoa()の実装に変更がない限り、（静的に割当 > > > られた領域から逸脱してデータを読み出すようなことをすれば確かに > > > 問題ですが）この領域の範囲内で必要となるIPアドレス文字列数分( > > > sizeof("aaa.bbb.ccc.ddd"))を指定して読み出すことになるだけ > > > ですので、18バイトまでの考慮は不要で16バイトのままで良いと考えます。 > > > > > > もちろん、今後IPv6対応化等において別途考慮は必要になりますが。。。 > > > > > > 特に異論等なければ、このままとさせていただきます。 > > > > > -- > Hideaki Kondo -- Hideaki Kondo -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: accesslog_addition_svn_diff.patch.gz 型: application/octet-stream サイズ: 733 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/ultramonkey-l7-develop/attachments/20081209/6cdf6a73/attachment.obj From makoto ＠ kanon-net.jp Tue Dec 9 14:51:19 2008 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Tue, 09 Dec 2008 14:51:19 +0900 Subject: [Ultramonkey-l7-develop 231] Re: =?iso-2022-jp?b?VU0tTDcgGyRCJSIlLyU7JTklbSUwPVBOTz1oTX0bKEI=?= =?iso-2022-jp?b?GyRCREkyQyRLJEQkJCRGGyhC?= In-Reply-To: <20081209144130.D9A2.KONDO.HIDEAKI@oss.ntt.co.jp> References: <20081209132151.D99F.KONDO.HIDEAKI@oss.ntt.co.jp> <20081209144130.D9A2.KONDO.HIDEAKI@oss.ntt.co.jp> Message-ID: 近藤 様 竹林です． お疲れ様です． パッチありがとうございます． r961 で反映していますので，svn up でアップデートされていることを ご確認願います． ---------------------------------------------------------------- Shinya TAKEBAYASHI E-mail : makoto ＠ kanon-net.jp GPG ID : FFD20D1F GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ---------------------------------------------------------------- Hideaki Kondo wrote in message <20081209144130.D9A2.KONDO.HIDEAKI ＠ oss.ntt.co.jp > *** Subject: [Ultramonkey-l7-develop 230] Re: UM-L7 アクセスログ出力処理追加につ いて *** Date: 2008/12/09 14:44:57 > > 竹林さん、各位 > > 近藤です > お疲れ様です。 > > 先に送付のパッチは、安定版Ver.2.0.0-1リリース > ソースに対するパッチファイルになっておりましたので、 > unstable/sachielに対するパッチを作成しましたので > 再送付させていただきます。 > > ご確認およびご対応の程よろしくお願い致します。 > From kondo.hideaki ＠ oss.ntt.co.jp Tue Dec 9 16:11:26 2008 From: kondo.hideaki ＠ oss.ntt.co.jp (Hideaki Kondo) Date: Tue, 09 Dec 2008 16:11:26 +0900 Subject: [Ultramonkey-l7-develop 232] Re: =?iso-2022-jp?b?VU0tTDcgGyRCJSIlLyU7JTklbSUwPVBOTz1oTX0bKEI=?= =?iso-2022-jp?b?GyRCREkyQyRLJEQkJCRGGyhC?= In-Reply-To: References: <20081209144130.D9A2.KONDO.HIDEAKI@oss.ntt.co.jp> Message-ID: <20081209160559.D9A5.KONDO.HIDEAKI@oss.ntt.co.jp> 竹林さん、各位 近藤です。 お疲れ様です。 リポジトリ反映有難うございます。 正しく反映されていることを確認しました。 コンパイル後の簡易動作チェックも行い、 本件パッチが期待通り動作していることも 確認しました。 他の方もご確認いただき、問題等ありましたら ご指摘願います。 以上よろしくお願い致します。 On Tue, 09 Dec 2008 14:51:19 +0900 Shinya TAKEBAYASHI wrote: > 近藤 様 > > > 竹林です． > お疲れ様です． > > パッチありがとうございます． > r961 で反映していますので，svn up でアップデートされていることを > ご確認願います． > > ---------------------------------------------------------------- > Shinya TAKEBAYASHI > > E-mail : makoto ＠ kanon-net.jp > GPG ID : FFD20D1F > GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F > ---------------------------------------------------------------- > > > > Hideaki Kondo wrote in message <20081209144130.D9A2.KONDO.HIDEAKI ＠ oss.ntt.co.jp > > > *** Subject: [Ultramonkey-l7-develop 230] Re: UM-L7 アクセスログ出力処理追加につ > いて > *** Date: 2008/12/09 14:44:57 > > > > 竹林さん、各位 > > > > 近藤です > > お疲れ様です。 > > > > 先に送付のパッチは、安定版Ver.2.0.0-1リリース > > ソースに対するパッチファイルになっておりましたので、 > > unstable/sachielに対するパッチを作成しましたので > > 再送付させていただきます。 > > > > ご確認およびご対応の程よろしくお願い致します。 > > -- Hideaki Kondo