トップページ⇒tech
1001コメント292KB

ネットワークプログラミング相談室 Port15

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/09/30(金) 22:54:08
主にソケットに関しての質疑応答スレです。

Programming UNIX Socket FAQ (日本語訳)
  http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
  http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

関連リンクは>>2-10辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port14
http://pc8.2ch.net/test/read.cgi/tech/1118469143/
0488京子2005/11/11(金) 20:21:22
あのー心理テストのHP作りたいんですけど、結果のところで答えを
いくつかに分けなきゃいけないじゃないですか？やり方が分からないので誰か教えて頂けませんか？
どこで聞いたらいいか分からないので・・お願いします！
0489デフォルトの名無しさん2005/11/11(金) 20:22:46
>>488
Web制作
http://pc8.2ch.net/hp/
04904772005/11/11(金) 20:27:00
>>484さん
ご親切にありがとうございます。
unixの定番の書籍の方を検討してみたいと思います。（値段は高いスけど　＾＾；）
明日本屋へ探しに行ってみます
04914772005/11/11(金) 20:30:32
皆さんも貴重なご意見を、有難うございました。
0492デフォルトの名無しさん2005/11/11(金) 21:16:25
商用UNIXこそが本流だよ。
まがい物にだまされないように。
0493デフォルトの名無しさん2005/11/11(金) 21:17:29
本物はソラリスだけ
でも最近無料とかオープンソースとか下品なことやってるので心配
0494デフォルトの名無しさん2005/11/11(金) 21:46:19
MMO作ろうと思ってんだが、とりあえずマルチスレッドで複数クライアントでチャットが出来るようにしたい。
サーバーはDOSプログラムの方がいいよな？
スレッドの種類はとりあえず、接続・受信・送信スレッドでいいよな
1対1の通信は出来たんだが、複数人でチャットするにはどうすればいい？
非同期だから、select使うのはわかるが・・・
0495デフォルトの名無しさん2005/11/11(金) 21:52:29
>>494
とりあえず>>1の
>Winsock Programmer's FAQ (日本語訳)
>http://www.kt.rim.or.jp/~ksk/wskfaq-ja/
は通読しといた方がいいぞ。
これ読まないとできることが分からないから設計できないでしょ。
0496デフォルトの名無しさん2005/11/12(土) 02:13:13
>>487
むしろ日本人のフリーソフトにそういうの多くないか
BSDライセンスだけど転載のときは連絡をするのが「礼儀」だとか
だったらライセンスに書いとけと
0497デフォルトの名無しさん2005/11/12(土) 02:16:31
>>496
あるあるｗ
0498デフォルトの名無しさん2005/11/12(土) 02:57:30
GPLだけどソースは公開しないし、望外な値段でなら見せるよって所も多い悪寒。
だったらGPLって言うな。
0499デフォルトの名無しさん2005/11/12(土) 03:23:44
そんな事は無いから。馬鹿は黙ってろ。
0500デフォルトの名無しさん2005/11/12(土) 08:30:05
ライセンスの話は専用のスレで。
0501デフォルトの名無しさん2005/11/12(土) 23:29:21
日本人はライブラリに弱いからな
改良は得意だけど本流を作る能力がないってのが原因か。
0502デフォルトの名無しさん2005/11/13(日) 18:44:55
.NET 2.0(Visual C# 2005 Express)でソケット通信のサーバプログラムを非同期式に書こうと思っています。
イメージとしてはGUI(Form)アプリケーションのStartやStopボタンで制御するWebサーバのようなものです。

メインのクラスではBindしてListenしたSocketに対し、コールバック関数を指定してBeginAcceptとしています。
コールバック関数ではEndAcceptして処理してShutdownしてCloseしてからBeginAcceptとしています。

ここでお聞きしたいのですが、メインのクラス側からこのサーバを停止させたいと思うのですが、
そのままメインのクラスでShutdownしてCloseしようとするとコールバック関数のEndAcceptで例外が発生します。
既に閉じられたSocketに対してEndAcceptするからだと思います。

このようなケースではどのようにするのが定石なのでしょうか。
0503デフォルトの名無しさん2005/11/13(日) 18:57:20
え？コネクション毎にListeningSocket閉じてるの？
0504デフォルトの名無しさん2005/11/13(日) 19:14:03
>>502
そのようなケースでは貴方が業界から去ることが定石です。
0505デフォルトの名無しさん2005/11/13(日) 19:34:14
>>494
> とりあえずマルチスレッド

お前みたいなヴォケがいるから
糞スレになるんだよ
0506デフォルトの名無しさん2005/11/13(日) 19:39:17
>>505
お前みたいに釣られる屑がいるから
糞スレになるんだよ
0507デフォルトの名無しさん2005/11/13(日) 21:15:14
お
0508デフォルトの名無しさん2005/11/14(月) 12:14:39
>>501
ヲレライブラリを作ると、車輪の再発明とか逝って叩こうとする風習が有るのも問題。
なんか天才じゃないとライブラリ作っちゃダメみたいなところはあるよな。

日本発のソフトなんてことごとく批判されるし、育たない。
亜米利加人が適当に作ると、すぐ日本語化対応されて広まるのとは対象的。
0509デフォルトの名無しさん2005/11/14(月) 12:35:37
>>502
このような時マジレスされないのが定石
0510デフォルトの名無しさん2005/11/14(月) 12:49:21
>>508
日本のはただのラッパー
メインルーチン隠しておまけにいくつかの機能潰してそれが何かの役に立つわけ？
汎用ですよー、速いですよーって機能縮小してなにをいってるんだか
向こうはSocketでもDirectXでも機能を付け足していってるのに
日本は元APIに無いからそんな機能は無理ですってアフォだろ
アメリカなんて叩かれることすらなく消えていくのがほとんどなのに
ちょっと注目集めたらすぐに放り出してギャラリーのせいにする
方向性がボケてるから外野の声に惑わされるんだよ
0511デフォルトの名無しさん2005/11/14(月) 13:06:54
>>510
「日本のはただのラッパー」というラップの歌詞かと思った
0512デフォルトの名無しさん2005/11/14(月) 15:16:22
Yo! Yo! 日本人! Yo!
0513デフォルトの名無しさん2005/11/14(月) 16:31:09
>>510
> 向こうはSocketでもDirectXでも機能を付け足していってるのに
> 日本は元APIに無いからそんな機能は無理ですってアフォだろ

SocketのIPv6拡張は日本人の貢献も大きいんだが?
0514デフォルトの名無しさん2005/11/14(月) 17:04:58
IPv6「拡張」って言ってる時点でオリジナルではない希ガス
0515デフォルトの名無しさん2005/11/14(月) 18:35:04
>>512
わろた
0516デフォルトの名無しさん2005/11/14(月) 18:46:15
>>514
> オリジナルではない希ガス

>>510
> 機能を付け足していってるのに
> 日本は元APIに無いからそんな機能は無理です

そもそもIPv6に日本人の寄与があるって書くと、v6だからオリジナ(ry
0517デフォルトの名無しさん2005/11/18(金) 03:37:13
Windows上でIPv6に対応したLinuxのようなtraceroute(UDP撃ってICMP受ける)を作りたいのですが、
IPv4はできたのですが、IPv6がうまいこといきません。
WinsockでIPv6のRAWモードソケットってちゃんと使えるのでしょうか？
やっぱりWinPCapが必要なのかな...
0518デフォルトの名無しさん2005/11/18(金) 05:41:39
AF_INETソケットだと、IPv4しか取得できない。
UNIXの場合は、socket(2)の第三引数にIPPROTO_RAWを指定すると何でも取得できる。

WinPcapはlink-layer network accessを使っている。
0519デフォルトの名無しさん2005/11/18(金) 06:07:34
とりあえず、XP以降じゃなきゃ無理だとは想ったけど
0520デフォルトの名無しさん2005/11/18(金) 23:20:02
IRCの通信内容の概要とかを分かりやすく解説したサイトってないでしょうか
RFCの日本語訳を読んだんですがさっぱりで。
0521デフォルトの名無しさん2005/11/18(金) 23:35:54
>>520
PING
PONG
05225202005/11/18(金) 23:43:51
>>521
すみません、どういう意味でしょうか
0523デフォルトの名無しさん2005/11/19(土) 00:27:38
>>522
ほんとにRFC読んだのか…？
0524デフォルトの名無しさん2005/11/19(土) 06:24:18
>>516
IPv4にインスパイアされてアドレス空間を増やしてみましたが
IPv4の使用を制限するものではありません
0525デフォルトの名無しさん2005/11/19(土) 09:21:10
むしろIPv4から派生したIPv6が有名になっていくことに
IPv4の方々が喜んでくれるのではとも思っていました
0526デフォルトの名無しさん2005/11/19(土) 11:29:28
そこは「インスパイヤ」と書かないと
0527デフォルトの名無しさん2005/11/19(土) 18:13:24
inspiya
0528デフォルトの名無しさん2005/11/19(土) 21:55:09
WSARecvで非同期で受信する方法としては何がありますか？
CompleteRoutinもWSAOVERLAPPEDのhEventも使わず、
WSAGetOverlappedResutも使わない場合、他に受信する手だてはありますか？
Winsok2はどうもわけがわかりません。
0529デフォルトの名無しさん2005/11/19(土) 22:09:46
他に(winsock非標準ながら)IOCPにする手も無くはないが、
意味的にはGetOverlappedResultと大差ないし。
つーか、自分で挙げた手段では何が不満なの？
0530デフォルトの名無しさん2005/11/19(土) 22:19:30
IOCPってI/O completeってやつですか？
そこらへん解説してる本とかってありませんか？

WinsockやWinowsのI/Oの仕組みが全然わかってないので、
どういう方法で通信が出来るのかが知りたいのです。
Winsock FAQを読むと、もっと効率の良い方法があるのかなと思いまして。
0531デフォルトの名無しさん2005/11/19(土) 23:04:28
つまり、自分で調べる気も勉強する気もないと。
0532デフォルトの名無しさん2005/11/19(土) 23:14:10
ここで聞いたら簡単に勉強できるかなと思いまして
0533デフォルトの名無しさん2005/11/19(土) 23:16:50
自分で調べるの面倒なんですよ
0534デフォルトの名無しさん2005/11/19(土) 23:21:27
「Win32ネットワークプログラミング」にだいたい書いてあった気がする
05355302005/11/20(日) 09:04:07
そんなに教えて君な書き込みだったでしょうか。
当然、531,533は偽者です。

IOCPに関して書いてある書籍でもあれば買って
それを読んで勉強しようと思っています。
どうも"complate"とか"port"とか一般的な単語のせいで
いまいちgoogleでの検索ヒットも芳しくありません。

もしよろしければ、せめて幾つかお薦めの検索キーワードだけでも教えていただけないでしょうか？

>>534
読んでみるとします。
0536デフォルトの名無しさん2005/11/20(日) 09:16:39
IOCP
CTRL+F
05375172005/11/20(日) 09:18:52
>>518
AF_INET6を指定すれば、IPv6のパケットを拾える、
ということではないのでしょうか？
MSDNヘルプには出来るとも出来ないとも書いてないもので。

>>519
実行環境はXPのSP2です。
開発環境はVisual Studio .NET 2003 + Platform SDKです。
0538デフォルトの名無しさん2005/11/20(日) 23:53:36

ttp://mzweb2.econ.doshisha.ac.jp/1998/Study/tuusin/tera.html
ここにあるソースをコンパイルして実行すると、

java.net.BindException: Permission denied
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
at java.net.ServerSocket.bind(ServerSocket.java:318)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at java.net.ServerSocket.<init>(ServerSocket.java:141)
at Receiver.mainproc(Receiver.java:123)
at Receiver.main(Receiver.java:137)

このようなメッセージが出てきて実行できません。
このエラーメッセージはMacOSのターミナルからの場合ですが、LINUXマシンからもpaermission系のエラーで動かないようです。

とりあえずこのプログラムを走らせてみたいのですがどこをどう設定すればいいのかよくわからないのです。

ものすごく初歩的な質問だとは思うのですが、どなたかお答え頂けませんか？
0539デフォルトの名無しさん2005/11/21(月) 00:01:53
1024より下のポートにbindするには特権が要る。
Linuxなら、rootか。MaxOSは知らんが、基本がUNIX系なら、
同じように管理者系の権限が要るはず。
05405382005/11/21(月) 00:30:25
>>539
LINUXではrootログインで解決できました。ありがとうございます！

MacOSではrootログインの仕方がよくわからないので調べてみます。
0541デフォルトの名無しさん2005/11/22(火) 00:35:52
>>540
> MacOSではrootログインの仕方がよくわからないので調べてみます。

sudo
0542デフォルトの名無しさん2005/11/22(火) 01:42:46
winpcap 3.1b4のドライバってカスタムハックドライバだよな？
なんかウイルスがどうのこうのとか出るときあるんだがこいつ
raw socketでも見にいってるのか？ちなみにWin2000でもwinXP SP1でもSP2
でもそうなる。怪しいよな
05435382005/11/22(火) 18:13:22
>>541
実行できました。ありがとうございます。
0544デフォルトの名無しさん2005/11/22(火) 21:19:24
winpcapは悪用されることも多いのでウィルスとして検出されがち
0545デフォルトの名無しさん2005/11/24(木) 02:19:35
Winでネットワークのドライバを作りたいのですが資料となるものを
集めたいのですがどこから手をつけたらいいのか教えてください。
0546デフォルトの名無しさん2005/11/24(木) 06:30:37
>>545
NDIS
0547デフォルトの名無しさん2005/11/28(月) 22:35:00
現在マルチスレッドにて通信プログラムを作成しているのですが、
IOスレッドとaccept()スレッドに分かれており、ユーザーの入力に
より任意のタイミングでaccept()スレッドを終了させたいのですが、
accept()ではずっと待ち状態になってしまっているのでどうしたら
よいのかが皆目見当もつきません。
何かいい案はないでしょうか？
0548デフォルトの名無しさん2005/11/28(月) 22:43:12
connect()
0549デフォルトの名無しさん2005/11/28(月) 22:43:36
select系でソケットと一緒にパイプやEventを待つ
0550デフォルトの名無しさん2005/11/28(月) 23:00:04
close()で抜けて来るようにお願いする
0551デフォルトの名無しさん2005/11/28(月) 23:19:16
close()さん抜いてください。
0552デフォルトの名無しさん2005/11/29(火) 00:37:33
>>547
退職する。これ名案。
0553デフォルトの名無しさん2005/11/29(火) 07:58:56
>>540
linuxでもsudoの癖付けた方がいいよ。
運用ではroot権限でなんて怖くて動作させないだろうし。
0554デフォルトの名無しさん2005/11/29(火) 08:22:08
>>547
接続をaccept()でなく、select()→accept()で待つ。
0555デフォルトの名無しさん2005/11/29(火) 23:02:43
「TransmitPacketsが使える環境なら使う」を同一実行ファイルでやろうとする場合、
LoadLibrary+GetProcAddressではなく、WSAIoctlにSIO_GET_EXTENSION_FUNCTION_POINTERを渡すのが
正統で保証されたやり方なのね。
前者だと、自動的にリンクされるものと同じDLLを複数回ロードすることになって
両方を経由しての呼び出しで整合性が保証されるのか、若干の不安があるし。
0556デフォルトの名無しさん2005/11/30(水) 03:02:07
>>552
最後のプロセスがcloseすると手放しちゃうからな
それは会社としてまずい
0557デフォルトの名無しさん2005/12/02(金) 00:39:30
SetSockOpt()でSO_RCVBUF(受信バッファ)を32KBに設定したんですが
イーサリアルでwindow sizeを見ても64240(←デフォルト？)から
変更されてませんでした。
GetSockOpt()で取得すると32KBとなってます。

ソケットに対して設定はされているようですが
適用されていないような感じがします。

どなたかなにか分かる人いますか？
[WinXp VC6 MFC CAsyncSocket]

ちなみにレジストリをいぢる(追加する)とちゃんと
window sizeがかわってました。

0558デフォルトの名無しさん2005/12/02(金) 06:36:00
>>557
もう一回勉強しよう。
答え：バッファサイズとウィンドウサイズは関係がない。
0559デフォルトの名無しさん2005/12/02(金) 17:54:31
>答え：バッファサイズとウィンドウサイズは関係がない。
初耳だ。
0560デフォルトの名無しさん2005/12/02(金) 18:23:31
>>560
じゃあどういう関係があるかの説明と>>557の原因についての講釈をキボンヌ。
0561デフォルトの名無しさん2005/12/02(金) 18:55:15
560の講釈を拝聴するスレになりました
0562デフォルトの名無しさん2005/12/02(金) 18:56:13
コネクション成立後にSetSockOptを呼んだに一票。
0563デフォルトの名無しさん2005/12/02(金) 19:20:19
>>559
関係があるって聞いた覚えもないなｗ
0564デフォルトの名無しさん2005/12/02(金) 19:28:02
それは勉強不足。
ttp://www.microsoft.com/japan/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
0565デフォルトの名無しさん2005/12/02(金) 23:30:52
>>564
アホですか?
0566デフォルトの名無しさん2005/12/03(土) 00:06:49
557です。

>>558
自分は
受信バッファ≒window size
ぐらいに思っていたので全く関係がないことはないと
思っているのですが、いかがでしょうか？
ちょっとして根本的になにかまちがってます？自分...

>>562
さすがにそれはないですｗ
0567デフォルトの名無しさん2005/12/03(土) 00:41:02
An Interdisciplinary Approach to Designing Fast Networked Devices
これ読んで勉強しているのだがイマイチプログラム書き方がわからない
何か他にいい本紹介してくれないか？
0568デフォルトの名無しさん2005/12/03(土) 00:45:08
>>567
＞プログラム書き方がわからない
”３日で覚えるC言語”みたいな本から始めたら？
カッコつけて難しい本読まなくていいじゃん。
0569デフォルトの名無しさん2005/12/03(土) 01:05:03
>>566
SO_RCVBUFはTCPウィンドウサイズとは別ものです。

http://msdn.microsoft.com/library/?url=/library/en-us/winsock/winsock/setsockopt_2.asp

SO_RCVBUF
int
Specifies the total per-socket buffer space reserved for receives.
This is unrelated to SO_MAX_MSG_SIZE or the size of a TCP window.


送信バッファ、受信バッファ、ＴＣＰウィンドウの説明は以下にあります。
http://www.7key.jp/nw/window.html#window
0570デフォルトの名無しさん2005/12/03(土) 01:22:59
>This is unrelated to SO_MAX_MSG_SIZE or the size of a TCP window.
これはSO_MAX_MSG_SIZEとは関係なくて、TCP windowのサイズです。
0571デフォルトの名無しさん2005/12/03(土) 01:47:21
>>569
>>564のリンク先に
>DefaultReceiveWindow
>値の種類 : REG_DWORD
>既定値 : 4096/8192/8192
>説明 : フロー制御を適用する前に AFD が接続上でバッファに格納する受信バイトの数。
>アプリケーションによっては、この値を増やすと、パフォーマンスが若干向上することがあります。
>ただし、リソースの使用率が大きくなります。
>アプリケーションからこの値をソケット別に変更するには、SO_RCVBUF ソケット オプションを使用します。
って書いてあるけど、これは大嘘?
0572デフォルトの名無しさん2005/12/03(土) 08:35:05
>>571
お前はTCPの"window"って概念を理解してないんだから、
せめて>>569の挙げてくれたURLを精読するまで発言するな。

>>570
これはSO_MAX_MSG_SIZEにもTCP windowのサイズにも関係ありません。

>>564のページの
> 受信ウィンドウのサイズを特定の値に設定するには、次の 2 通りの方法があります。
> ・"TcpWindowSize" レジストリ パラメータ (「付録 A」参照)
> ・Windows Sockets の "setsockopt" 関数 (ソケット別の設定)
は間違いな。

前者は「提示可能な TCP 受信ウィンドウ の最大サイズ」(動作中小さくなりうる)
後者は「内部バッファの合計サイズ(送受別)」
0573デフォルトの名無しさん2005/12/03(土) 08:35:49
>>566
全く関係がないとは誰も言ってない。
0574デフォルトの名無しさん2005/12/03(土) 08:50:38
>>572
>Windows Server 2003 では、アドバタイズした TCP 受信ウィンドウの既定サイズは、以下の要因に依存します。
>なお、これらの要因は優先度の高い順に示してあります。
>1.接続の SO_RCVBUF WinSock オプション。
>2.インターフェイス別の TcpWindowSize レジストリ設定値
>3.グローバル TcpWindowSize レジストリ設定値
0575デフォルトの名無しさん2005/12/03(土) 09:13:33
>>573
以下の3人は関係がないと思っているようですが。

>>558
>答え：バッファサイズとウィンドウサイズは関係がない。
>>563
>関係があるって聞いた覚えもないなｗ
>>572
>これはSO_MAX_MSG_SIZEにもTCP windowのサイズにも関係ありません。
0576デフォルトの名無しさん2005/12/03(土) 14:09:18
>>575
「関係」って単語でレス抽出するんじゃなくて、内容よく読んだほうがいいよ。
最後のやつなんてmsdnそのまま訳しただけじゃん。msdnに文句言いたいの？
0577デフォルトの名無しさん2005/12/03(土) 15:25:21
パフォーマンス改善には関係あるけど、直接には関係ないでしょ。
バッファとウィンドウって別の物だし。
0578デフォルトの名無しさん2005/12/03(土) 15:37:37
>>570
英語勉強しなおせ
0579デフォルトの名無しさん2005/12/03(土) 22:58:48
UNIX 系 OS だと、SO_RCVBUF と、受信ウィンドウの最大値は同じだよ。
Windows 系がそうじゃなくて、SO_RCVBUF よりも大きな値になるって
ことの方が驚いた。
0580デフォルトの名無しさん2005/12/03(土) 23:04:28
> バッファとウィンドウって別の物だし。

受信ウィンドウってのは、あとどれくらい受けとれるかを通知する値。
だからバッファサイズよりも受信ウィンドウが大きいというのは、変。
もちろんウィンドウが開ききるまでは
　バッファの空きサイズ＞受信ウィンドウ
ということはありうる。でも
　バッファサイズ＜受信ウィンドウ
ってことはありえない。

というのが UNIX のソケット実装での常識。
0581デフォルトの名無しさん2005/12/03(土) 23:14:07
OSはLinux、コンパイラはgcc。
struct sockaddr_in構造体を使用する前にmemset(3)でゼロクリアしてる
例をよくみかけますが、なぜゼロクリアしているのですか?

/* 例 */
struct sockaddr_in to;

memset(&to, 0, sizeof to); /* ゼロクリアしてるのはどうしてなぜ? */
to.sin_addr.s_addr = inet_addr(ip);
to.sin_family = AF_INET;
to.sin_port = htons(port);
0582デフォルトの名無しさん2005/12/03(土) 23:18:56
sin_addr.s_addr, sin_family, sin_port 以外のフィールドにも
意味があるかもしれない、あるいは今は意味がなくても、将来
拡張されて意味があるようになるかもしれないから。
ゼロクリアしておけば、そういう場合でも互換性が保障される。
0583デフォルトの名無しさん2005/12/03(土) 23:19:20
予防的措置。

memset後の3行が全体を覆うという保証があるならいいけど、
Linuxのような紛い物のunixだとそうはいかない
0584デフォルトの名無しさん2005/12/03(土) 23:23:05
>>581
そのようなコーディングをよく見かけます。
個人的には、memset関数などによるゼロクリアは好きではない。
あまりお勧めしません。
構造体を初期化するなら、各々のメンバー変数ごとに、初期値を代入すべきであろう。
初期化する必要のないメンバー変数は、初期化する必要もなかろう。

memset関数などによるゼロクリアの利点をあえて挙げるとすると、メモリダンプしたとき、
見やすいということはある。

0585デフォルトの名無しさん2005/12/03(土) 23:23:56
> Linuxのような紛い物のunixだとそうはいかない

別にLinuxに限らず、あの3行で struct sockaddr_in の
全てを多うOSなんてないのでは？ もしあったら、OSの
名前とバージョン、struct sockaddr_in のコピペきぼん。
0586デフォルトの名無しさん2005/12/03(土) 23:25:52
俺はさ、sockaddr_inをバイナリで扱う処理系があるから０クリアしろって覚えたんだけど。
0587デフォルトの名無しさん2005/12/03(土) 23:26:47
> 構造体を初期化するなら、各々のメンバー変数ごとに、初期値を代入すべき
> であろう。

現在存在しないメンバー変数が、将来拡張されて増えるという可能性
もある。そういう場合、初期値の代入は、やりたくてもできない。

> 初期化する必要のないメンバー変数は、初期化する必要もなかろう。

ゼロクリアしておかないと、将来メンバーが増えたときに困る。

実際、*BSD では 1990年頃に sin_len というメンバー変数が増えたわけだし。
■ このスレッドは過去ログ倉庫に格納されています