5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

UNIXプログラミング質問すれ Part3

1 :実行されるのでしょうか?:04/05/31 00:28


UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド

前スレ:
http://pc5.2ch.net/test/read.cgi/tech/1055110889/
http://pc2.2ch.net/tech/kako/992/992057422.html

>>2 関連スレ

2 :デフォルトの名無しさん:04/05/31 00:33
test

3 :デフォルトの名無しさん:04/05/31 00:43
>>1
立て逃げせずに関連スレ張れよ馬鹿



4 :デフォルトの名無しさん:04/05/31 01:07
関連スレ
Cygwin使っている人いますか? その11(UNIX板)
http://pc5.2ch.net/test/read.cgi/unix/1076240971/
Cygwin使っている人いますか? Part2(Windows板)
http://pc5.2ch.net/test/read.cgi/win/1052361218/

関連板
http://pc5.2ch.net/unix/
http://pc5.2ch.net/linux/



5 :デフォルトの名無しさん:04/05/31 03:31
前スレ>>992
で,お前は一体,何を言いたいんだ。
一人,自己完結して終い?

6 :デフォルトの名無しさん:04/05/31 06:43
>>5
みっともない。。。

7 :デフォルトの名無しさん:04/05/31 08:15
しかし>>992はtrapくらい検討するべきだったろう
トラブってもマニュアル読まない人?

8 :デフォルトの名無しさん:04/05/31 09:07
>>5
初めの実装ではスクリプトの中で'&'付けてコマンドを実行するようにしていました。
OS起動によりスクリプトを起動したら、ログイン後に実行し続けている
はずのコマンドのプロセスがなくなっていました。そこでなぜかと
調べているときに、他のアプリケーションのスクリプトでは'&'を付けて
起動しているコマンドがほとんどないことに気が付きました。
根本的な知識がなかったために質問させてもらいました。

>>7
自分ひとりで検討したわけではないのですが、何かまずい欠点などあったら
指摘してもらえますか?

9 :デフォルトの名無しさん:04/05/31 09:10
マニュアルを読んでない。

10 :デフォルトの名無しさん:04/05/31 09:17
>>9
nohupのマニュアルの中に何がまずいかは書いてあるから読め
ということでしょうか?
読んだ結果決定したことなので今更何ともいえないです。

11 :デフォルトの名無しさん:04/05/31 09:41
trapというキーワードが与えられているのに、
マニュアルを再読しないの? ああ、もう済んだことだしね。

12 :デフォルトの名無しさん:04/05/31 10:26
>>11
再読はしています。済ますつもりもありません。
ハングアップのシグナルを無視してコマンドを実行するという点で
まだ違いが読み取れていません。

13 :デフォルトの名無しさん:04/05/31 12:28
"nohup.out"なんつー謎のファイルが出現して,精神衛生上悪い。

そもそも,>>990に'&'の恐ろしい害が書いてあるのは,ちゃんと理解したのか?
>>992の「僕不安なの〜」なんてレス見る限り,全く理解していないように思うのだが。

14 :デフォルトの名無しさん:04/05/31 13:06
"nohup.out"なんつー謎のファイルが出現して,精神衛生上悪い。

そもそも,>>990に'&'の恐ろしい害が書いてあるのは,ちゃんと理解したのか?
>>992の「僕不安なの〜」なんてレス見る限り,全く理解していないように思うのだが。

15 :デフォルトの名無しさん:04/05/31 22:55
>>13
さっさと答えを書けばよいのでは?
そんなことで儚い優越感に浸っても仕方がないだろう。

16 :デフォルトの名無しさん:04/05/31 23:13
>>15
必死だな

17 :デフォルトの名無しさん:04/05/31 23:21
>>16
オマエモナー

18 :デフォルトの名無しさん:04/06/04 06:02
POSIXのシグナルで、一つのハンドラを複数のシグナルに登録することはできますか?

19 :デフォルトの名無しさん:04/06/04 07:43
できます。

20 :デフォルトの名無しさん:04/06/05 20:01
selectシステムコールを使っていてタイムアウトは設定していないのに戻り値に-1が入って抜けてしまいます。
シグナル割り込みが発生していると思うのですがシグナルを無視するような方法なんてあるのでしょうか?


21 :デフォルトの名無しさん:04/06/05 21:04
signal関数でできるかもしれない。
いずれにせよ、なんで-1が返ってるのかを確認するのが先だと思うが。

22 :デフォルトの名無しさん:04/06/05 21:25
>>20
とりあえずerrnoがEINTRかどうか見てから判断しても遅くはないだろう
signalは無視することもできるが、単に無視しちゃまずい
場合もあるだろう(子プロセスからのSIGCHLDを待ってる場合など)

sigaction()なら古いsignal()より細かい制御ができるが、
sigaction()がサポートされてるかどうかとか
どんなシステムコールが再開をサポートしてるかとか
その辺はシステムによるんで、結局
while ((n_read = read(fd, buff, sizeof buff)) == -1 && errno == EINTR)
;
みたいにループにしちゃうのは良く使う手だ


23 :20:04/06/05 21:38
>>21 >>22
ありがとうございます。
とりあえずerrnoを見てEINTRならループで回すことにします。

24 :デフォルトの名無しさん:04/06/06 05:55
>>20-23
errnoチェックすんのはUnixの鉄則ではないか。


25 :デフォルトの名無しさん:04/06/06 09:40
別に Unix に限ったことじゃないと思うが...。
(Windows は GetLastError() だったりするけど。)

ていうか、>>20 は場当たり的杉。
select が -1 を返す
⇒ 「シグナル割り込みが発生していると思う」
⇒ 「シグナルを無視する」

errno みて、「あっ ! 割り込まれてんじゃん !!」とわかったら、「誰がシグナル送っとんじゃ、ゴラァー !!」と思うのが普通だと思ってたけど、最近はみんなこうなのか ?

26 :デフォルトの名無しさん:04/06/06 10:22
>>25
サンプル数1で全国の星の数ほどいるプログラマの考え方はこれだと決定するのですね。
最近はみんなそ(略


ときに、誰がシグナルを投げたかなんてわかるんですか?

27 :デフォルトの名無しさん:04/06/06 18:04
>>26
わかる。ぐぐれ。

ヒント: sigaction
(ヒントっていうかそのものか。藁)

28 :デフォルトの名無しさん:04/06/06 18:58
>>26
>> 最近はみんなこうなのか ?
> サンプル数1で全国の星の数ほどいるプログラマの考え方はこれだと決定するのですね。

どこを見て「決定している」と判断しているか非常に興味がある。
最近は、こういう奴も多いのか ?

29 :デフォルトの名無しさん:04/06/08 23:58
UNIXダサすぎ。
つかってて平気ですか?

30 :デフォルトの名無しさん:04/06/09 00:09
>>29
みんな我慢汁がまんしてる。

31 :デフォルトの名無しさん:04/06/09 00:14
↓久しぶりにキモーイのAAよろしこ。

32 :デフォルトの名無しさん:04/06/09 00:29
UNIX最高なんだけどぉ

33 :デフォルトの名無しさん:04/06/09 02:49
>>29
UNIX好きさ。快適だ。
君は何がいいと思うんだ?

34 :デフォルトの名無しさん:04/06/09 04:32
OpenVMS

35 :デフォルトの名無しさん:04/06/09 11:42
Unix最高だぜ!
一度Unixの良さを知ったら他の奴にはもう戻れない。


36 :デフォルトの名無しさん:04/06/09 18:20
ここの住人はSmalltalkやInterlisp-Dみたいな環境使ったことないんだろうなあ。

37 :デフォルトの名無しさん:04/06/09 19:32
Squeakが玩具である事だけは確認しました。

38 :デフォルトの名無しさん:04/06/09 19:46
複数人が同時にログインして作業できるOSって、他にないからなあ。
UNIXがなかったらと思うとぞっとするよ。


39 :デフォルトの名無しさん:04/06/09 19:51
viみたいな知障エディタしかないので
なにもできない。

40 :デフォルトの名無しさん:04/06/09 19:57
本物のviを使えるなんてすごい環境だな。

41 :デフォルトの名無しさん:04/06/09 20:52
UNIXはなんか問題が起るとlibcやカーネルのソースまで
おいかけて問題を探さなくちゃならない。ハッカーじゃない
普通の人の精神状態を平静に保つには、クローズドな
システムがよい。分業と称した責任の擦り付け合い。

42 :デフォルトの名無しさん:04/06/09 21:02
>> 41
> クローズドなシステムがよい。
例えば?


43 :デフォルトの名無しさん:04/06/09 21:36
>>36
あなたが本当に Smalltalk や Lisp の信奉者であるなら UNIX の良さが分かると思うけど
(こないだ Medley 触ってみたけど、今の時代にあの中で生活するのは厳しいかな)。

44 :デフォルトの名無しさん:04/06/09 21:57
2chの鯖だって、本当は原因追求しなくちゃいけない。
rootさんに悪いからあんまり触れないけど。

>>42
Solaris
ちなみに俺の中ではクローズドなUNIXなるものはない。

45 :デフォルトの名無しさん:04/06/09 22:13
41を44の返答で補ってみた.
> UNIXは(Solarisと違って)なんか問題が起るとlibcやカーネルのソースまで
> おいかけて問題を探さなくちゃならない。ハッカーじゃない
> 普通の人の精神状態を平静に保つには、クローズドな
> システム(例えばSolaris)がよい。分業と称した責任の擦り付け合い。

Solarisで開発したことないから,よく分かんないんですけど,
Solarisには,例え問題が起きてもlibcやカーネルのソースまで
追いかけなくても問題が解決する機構があるんでしょうか?

それとも,Solrarisのカーネルやlibcには,そもそも問題がないとの主張ですか?

「クローズド」の意味を私が理解できてないのかな?


46 :デフォルトの名無しさん:04/06/09 22:36
>>45
> Solarisには,例え問題が起きてもlibcやカーネルのソースまで
> 追いかけなくても問題が解決する機構があるんでしょうか?

サポートと言うありがたい機能がついてるからな。










あまり役に立たなかったりするけど...。

47 :デフォルトの名無しさん:04/06/09 22:47
商用のメリットって、わかんねえことはサポートに投げられることだよな。
UNIXに限らんけど。


48 :デフォルトの名無しさん:04/06/09 22:50
クソ遅いshが基本のUNIXなんて早く死滅すればいいのにね。。
shスクリプトあらかじめバイトコンパイルとかやってキャッシュ化するとかできんの?
どうせそれやっても遅だろうけど。

49 :デフォルトの名無しさん:04/06/09 22:54
shが遅ければPerlで書いてしまうというのもあるけどぉ?
それでも遅いと感じるなら、Cで書くしかないけど。

50 :デフォルトの名無しさん:04/06/09 23:14
シェルの処理速度が百倍速くても、殆ど体感的には誤差の範囲だと思うけど。
fork() とかコマンド自体の事なら、十分速いから無問題。

51 :デフォルトの名無しさん:04/06/09 23:20
だーから実際計ればわかるがshが一番時間食ってるんだよ。
クソ遅え。。
アホコマンド連発する文化だしな。

52 :デフォルトの名無しさん:04/06/09 23:24
>>51
そんなのは処理依存だし、時間掛かる処理に sh を使っているおまいが悪い。
つか UNIX の基本は sh じゃなくて C だろ。

53 :デフォルトの名無しさん:04/06/09 23:38
↑アフォ?
処理系依存て。

54 :デフォルトの名無しさん:04/06/09 23:40
↑日本語で書いたつもりだが・・・?

55 :デフォルトの名無しさん:04/06/09 23:40
処理依存と処理系依存の違いについて

56 :デフォルトの名無しさん:04/06/10 00:22
誰も処理系の話などしてない。

57 :デフォルトの名無しさん:04/06/10 05:33
shが時間食うか?
個々のコマンドの方が時間かかると思うのだが。

58 :デフォルトの名無しさん:04/06/10 18:13
さぁ、いよいよ荒れてきました。

59 :デフォルトの名無しさん:04/06/10 18:59
shが時間を食うと言うより、個々のコマンドのプロセスを生成/消滅させるのに時間を食う。

そろそろ終わりにしようや

60 :デフォルトの名無しさん:04/06/10 20:36
>>52
ですよね.

>>51
調べたと言うんなら,律速段階をCなりなんなり使って最適化すりゃいいじゃん.
あなたには選択の自由がある.


61 :デフォルトの名無しさん:04/06/10 20:53
まあshの場合「やりたい仕事の内容」と「それにかかる時間」が明らかに
見合わない場合はあるよね
その辺は適当に。
典型的な例がtestだのechoだのdateだのexprだのだ
まあ例をあげたらキリがないがな
これがshの組み込みになってない場合は明らかに時間がかかりすぎる
ループの中で使ったりしたらシャレにならん
一行メッセージを出力するだけのためにfdを複製しfork()exec()wait()
を実行するのは割りがあわなすぎる

ま、Cってのは極端だな
他のスクリプト言語が使えるならそっちを使えばいいだろう


62 :デフォルトの名無しさん:04/06/10 20:54
そこでCommonLispですよ!

63 :デフォルトの名無しさん:04/06/11 02:47
具体的にshにやらせていて、遅くて困ってるのって何?

64 :デフォルトの名無しさん:04/06/11 14:50
>>61
cは最終兵器だよな(w

>>63
イパーイある。俺が担当したうちのなかで一例を挙げると「ローダの無いRDBへの更新コマンド群の作成」
shで10時間ほどかかっていたのをawkに書きなおした。5秒になった。
shを使っていて遅いならば、それはshを使うのが悪い。
sh類は単なる「プログラマブルランチャー」だと思うべし

65 :デフォルトの名無しさん:04/06/11 14:59
Windows上のbatファイルで全てやろうとする変態がいたら見てみたいものだ。

66 :デフォルトの名無しさん:04/06/11 15:13
つか、shの中からawkなり自作プログラムなりを起動するのがふつうだろ。
shは個々のプログラムでは制御しにくい全体の処理フローを担当。

67 :デフォルトの名無しさん:04/06/11 20:17
一度書いたshを見直してみるのが一番はやいと思いますが・・

68 :デフォルトの名無しさん:04/06/11 20:47
どうだろう
むしろshベースのツールボックス的アプローチが伝統で
性能や機能にに問題があったら他のものを使う
が基本だと思うんだが、shの「ツールボックス的アプローチ」
がある意味「やりすぎ」なんだよな
echoだのtestだのexprだのまでが外だしってのは
昔のデザインなのにあそこまで富豪的なのはある意味すげえ

tclはコマンド(プロセス) が コマンド関数
に置き変わっただけでものすごくshに似てるけど
当たり前の話として、比べものにならないほど速いよね
インタプリタの中ではそれでも遅い部類だけど

Cなんて使うまでも無いことが多いよ。ただやっぱり
shの非効率は、時として次元が違いすぎるものになる。

69 :デフォルトの名無しさん:04/06/11 21:14
wgetはその基本的な機能をライブラリとして外に出して欲しいな。

70 :デフォルトの名無しさん:04/06/11 21:31
画像データを実行ファイルに埋め込んで使うことはできますか?
言語はC++です。

71 :デフォルトの名無しさん:04/06/11 22:25
できる。がんばって配列として打ちこみなさい。

72 :デフォルトの名無しさん:04/06/11 22:47
>>64
それは元のshell script書いた奴が糞だっただけかも知れないので、
目的じゃなくて、処理内容を書いてみなよ。(目的書いてどうする!?)

まあ、shell scriptでヘビーな文字列処理はやらない方がいい、
これは議論の余地がないけどな。お爺ちゃんも言ってた。

73 :デフォルトの名無しさん:04/06/11 22:48
>>70
xbm, xpm形式は、
画像データファイルそのものが、header fileとして利用できる。

74 :sh 厨がかかるかな ?:04/06/11 23:03
>>72
ネタかハッタリだろ。
いくら sh が遅いと言っても、awk の 7200倍も遅いわけがない。

75 :デフォルトの名無しさん:04/06/11 23:34
7199倍遅い

76 :デフォルトの名無しさん:04/06/12 00:37
>>74
そうだな、作りによっては7200倍どころじゃないだろうからな(w
以下のshスクリプトはcat -nの真似をするが(正確に同じではないが)
ここまで遅いものを他のスクリプト言語(awkを含む)で作るのは難しいだろう。
ためしにちょっとでかいファイルを読ませてみ。死ぬから。

ま、こんなものは当然誰もつくらない。すなおにcat -nを使えばよいからだ。
しかし、readもechoも、それをループの中で使うことも、それ自体では
ごく普通のshスクリプトで用いられる可能性がある点に注意だ。

for i
do
    exec <$i
    lineno=1
    while read line
    do
    echo $lineno "$line"
    lineno=`expr $lineno + 1`
    done
done


77 :デフォルトの名無しさん:04/06/12 01:09
諸悪の根源だが、
sh作った奴、アホだろ。
http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/mac.h.html

78 :デフォルトの名無しさん:04/06/12 01:17
その、アホが作ったshをいまだにありがたく使っている重度のアホもいる。
UNIXは基本的に、こうしたアホスパイラルで構築されている事が随所で観測できる。

79 :デフォルトの名無しさん:04/06/12 03:51
Bourneってここまでアホだったのか…

80 :デフォルトの名無しさん:04/06/12 04:17
>>77-79
有名なハナシだろそれ。
似たような風習は昔はちらほらあった。
現在の基準で過去を断罪すること勿れだよ。

>>76
単に処理の比率の問題だろ。
shスクリプトでループ回すときは内側の処理はもっと重いのが普通だし、
awkじゃできないこともある。

行番号つけるために>>76みたいなことして使えないと評価する奴がいるとしたら
適切な道具の使い方を知らないそいつの頭が使えないだけの話。


81 :デフォルトの名無しさん:04/06/12 08:42
>>72
数値計算もやらない方がいい。

>>76
長いわりに話のレベルが低くて激藁
どんな言語だってループ(再帰)はあるし、
ループの中で使える処理の重いサブルーチンがある。

そのfor文は…

82 :デフォルトの名無しさん:04/06/12 12:01
>>81

83 :デフォルトの名無しさん:04/06/12 12:12
>>76
> そうだな、作りによっては7200倍どころじゃないだろうからな(w

実際にやってみた。

OS: FreeBSD 4.7R
CPU: Pentium200MHz
Mem: 48MB

% /usr/sbin/time /tmp/76.sh /usr/src/sys/sys/* > /dev/null
  2088.41 real  85.80 user  394.67 sys
% /usr/sbin/time cat -n /usr/src/sys/sys/* > /dev/null
  0.56 real  0.44 user  0.11 sys

まあ、遅いが 7200倍も違わない。
ついでに言うと、誰が考えても expr の呼び出しに時間がかかっているのは明白。
FreeBSD の sh は数値演算を sh 自身でできるから、

10c10
< lineno=`expr $lineno + 1`
---
> lineno=$(($lineno + 1))

とした版を作ると

% /usr/sbin/time /tmp/76-1.sh /usr/src/sys/sys/* > /dev/null
  227.18 real  16.66 user  44.69 sys

と、400倍ぐらいになる。

84 :デフォルトの名無しさん:04/06/12 12:29
>>83
>FreeBSD の sh は数値演算を sh 自身でできるから、
と言うからには
>< lineno=`expr $lineno + 1`
>---
>> lineno=$(($lineno + 1))
これぐらいは内部で自動的に書き換えして欲しいよね。
互換性なくなるならイラネ。


85 :デフォルトの名無しさん:04/06/12 12:37
>>84
> これぐらいは内部で自動的に書き換えして欲しいよね。

(゚Д゚)ハァ?

> 互換性なくなるならイラネ。

歳幾つ? いまや$((数式))がないshの方が互換性がないんだけど…
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html

86 :デフォルトの名無しさん:04/06/12 12:38
>>84
そんな余分な自動化はいらんよ。
だいたい、expr がどんなプログラムかを sh が知っているわけじゃないんだし。

87 :デフォルトの名無しさん:04/06/12 12:49
shイラネ

88 :76:04/06/12 15:49
>>80
ごめんおれアホだから

> awkじゃできないこともある
awkぐらいにしか勝てないのですか?

>>81
何言ってるかわからないよ。もしかして俺よりレベル低いですか?

>>83
意外に早いな
ハノイの塔とかフィボナッチ数列にすべきだったか(w
確かに今どきのshellで明らかに遅くなるのはexprだけだろうな
あそこだけはどうしてもfork()&exec()とパイプからの読み取りが
発生するからな

>>85
でも今だにオープンソースのCの世界ではK&R風に書くかansi2knr.cは
つけるよね
Posix互換shellの機能は当然期待せずbourne shell互換に書くよね
>>76もそういうscriptのつもりなんだけど
互換性ってのはそういうことでしょ
C++なんかもっとひどいよね


89 :デフォルトの名無しさん:04/06/12 18:42
オープンソースだったら、shですべてやっちゃうような無茶なものは修正されるでしょ。

90 :デフォルトの名無しさん:04/06/12 18:53
>>88
> でも今だにオープンソースのCの世界ではK&R風に書くかansi2knr.cは
> つけるよね

gccにバリバリ依存しているものも多いですが…

91 :デフォルトの名無しさん:04/06/12 19:03
>>90
そうか?
どっちかというと、autoconfやgmakeに依存してるもののほうが多いような
気がするが
まあオープンソースといってもピンキリだからな

しかし、
・互換性を(さして)気にしなくていい
・極めてシビアな状況(/usr/binがつかえないなど)では実行できなくてもいい
んなら、shスクリプトにする必要なんぞどこにもない気がしないか
特にposix shなんて中途半端のきわみだという気がするが

92 :デフォルトの名無しさん:04/06/12 19:06
といって、他のスクリプト系だと非互換部分が大きすぎるし。
awkくらいまで枯れてればいいけど。

93 :デフォルトの名無しさん:04/06/12 19:13
いやshでもコマンド仕様自体はシステムによって非互換じゃん
よくあるのがecho()とかいう関数(echoのくだらないラッパー)

94 :デフォルトの名無しさん:04/06/12 19:18
バージョン違ったら動かねーとか、
そういう悲惨な状態にはなりにくいということ。

95 :デフォルトの名無しさん:04/06/12 20:26
FreeBSD の sh は、bash のシンボリックリンクじゃなかったっけ?

96 :デフォルトの名無しさん:04/06/12 20:38
>>95
ちがうちがう

97 :デフォルトの名無しさん:04/06/12 20:59
*BSDの/bin/shは同じコードなの?

98 :デフォルトの名無しさん:04/06/12 22:45
>>97
OpenBSDはかなり手が入ってる。Tab補完や履歴検索が出来るんで常用可。

99 :デフォルトの名無しさん:04/06/12 23:01
ま、POSIX互換が普通と思ってる奴は少ないわな

100 :デフォルトの名無しさん:04/06/12 23:42
ashだよな。

101 :デフォルトの名無しさん:04/06/13 00:44
>>98
bash?

102 :デフォルトの名無しさん:04/06/13 01:04
>>101
bashは(/bin/shとして起動した時にも)
独自拡張をoffに出来ないので*BSD方面では
/bin/shとしては評判が悪い。

103 :デフォルトの名無しさん:04/06/13 01:05
>>102
bashismですな。

104 :デフォルトの名無しさん:04/06/13 01:43
>>98
Openのshはksh(pdksh)だぽ

105 :デフォルトの名無しさん:04/06/13 03:25
cshイラネ

106 :デフォルトの名無しさん:04/06/13 03:26
つーかcshのどこがCに似てんだよゴルァ
言ってみろよゴルァ

107 :デフォルトの名無しさん:04/06/13 03:34
>>106
名前。

108 :デフォルトの名無しさん:04/06/13 04:13
そこで、zsh ですよ。

109 :デフォルトの名無しさん:04/06/13 05:51
bashって最悪。
$echo -eってしてみ。
さらに$printf -aのように-[a-zA-Z0-9]を表示しようとすると
オプションと勘違いするし…。

110 :デフォルトの名無しさん:04/06/13 07:39
Cで指定した時間が来たらシグナルを送ってくれるような関数ってありますか?
setitimerだとかなり時間がずれるので正確なのがあればいいんですけど。
OSはRHLinux9です。

111 :デフォルトの名無しさん:04/06/13 08:38
どれくらいの正確さを要求している?
秒?ミリ秒?ナノ秒?

112 :デフォルトの名無しさん:04/06/13 08:58
>>111
そこまで正確じゃなくて分単位程度の正確さを求めています。
夜間だけプログラムを動かして朝の7時に処理を止めたいので指定した時刻に
シグナルを送ってくれるような関数があればいいんですけど。

113 :デフォルトの名無しさん:04/06/13 09:02
itimerって分以上にズレるんか・・・知らんかった

114 :デフォルトの名無しさん:04/06/13 09:17
>>112
> 夜間だけプログラムを動かして朝の7時に処理を止めたい
それはat(またはcron)とkillの組み合わせでいいような...


115 :デフォルトの名無しさん:04/06/13 09:41
>>114
7時までに止めたいのは一部の処理でその後にもいくらか処理したいので
KILLはできません。
setitimerで1分ごとにシグナル送ってハンドラ内でtime関数を使って
設定時刻と比較するしかないのかな。
なんかもっとスマートな方法がありそうな気がするけど。

116 :デフォルトの名無しさん:04/06/13 09:54
>>115
man kill


117 :デフォルトの名無しさん:04/06/13 09:55
>>115
> KILLはできません。

それはKILL -TERMのことか? 他のsignal使えよ。、
setitimer(2)は分単位でずれることはないしな。

118 :デフォルトの名無しさん:04/06/13 10:00
clock_nanosleep+TIMER_ABSTIMEはどうだ?

119 :デフォルトの名無しさん:04/06/13 10:12
>>116-117
すいません。killについてよく知りませんでした。
確かになんとかなりそうです。ありがとうございます。

120 :デフォルトの名無しさん:04/06/13 10:19
>>119
名前が悪いよね


121 :デフォルトの名無しさん:04/06/13 12:14
デーモン作ってビジーループで時間見ても良いんじゃないかとね?

122 :デフォルトの名無しさん:04/06/13 12:18
ビジーループはまずい。

123 :デフォルトの名無しさん:04/06/13 12:19
>>121
そんなことしなくても、>>114 の方法で十分。

124 :デフォルトの名無しさん:04/06/13 16:57
>>120
同意

125 :デフォルトの名無しさん:04/06/13 17:00
kill me!

126 :デフォルトの名無しさん:04/06/13 17:39
昔、とある現場でファイルの構成管理にSCCSというのを使っていたので
懐かしく思い、いろいろ検索してはみたもののSCCSのダウンロードサイト
や解説ページが見つかりません。どなたかご存知ないでしょうか。


127 :ルナ:04/06/13 17:40
学校の課題で
「MIDIダイレクト、sound文で、音の高さのデータを共用したい。
あなたの考え方を述べなさい。」
というレポートを書かないといけないのですが、
図書館や本屋さんで調べても内容が難しくてわからず、何を
共用すればいいかもまったく検討もつきません。
どういう風にまとめればいいでしょうか?
何かアドバイスを頂ければと思い、ここに来ました。

答えにくい質問だとは思いますがどなたかアドバイスを
いただけると助かります。
お願いします!

128 :デフォルトの名無しさん:04/06/13 17:46
宿題スレに池

129 :ルナ:04/06/13 17:49
どこにあるんですか?


130 :デフォルトの名無しさん:04/06/13 17:52
>>126
商用 UNIX なら今でも入っています。フリーでは sccs 互換の cssc というプログラムが
あったんですが、今探したら見つかりませんでした。

131 :デフォルトの名無しさん:04/06/13 19:17
>>130
商用だと素で SCCS が入ってることが多いんだけど。
互換のやつはこれだよね。
http://cssc.sourceforge.net/index.shtml


132 :デフォルトの名無しさん:04/06/13 19:24
>>127
意味不明かつ意図が分からん。


133 :デフォルトの名無しさん:04/06/13 20:01
おれもよくわからんが、
「あなたの考えを述べなさい」だから、
「その内容では、何を言いたいのか分かりません」
でもいいんじゃないかと思った。

134 :デフォルトの名無しさん:04/06/13 21:13
Linuxでプログラミングの勉強を始めようと思っていまつ。
pythonから始めたほうがいいとハッカーサイトに書いてあったのでつが
なにを組んでいいのかわかりません。
Cは少し勉強したことがありまつ。

ハッカーになりたいのでつ
よろしくでつ

135 :デフォルトの名無しさん:04/06/13 21:17
>>134
ハッカーになりたいならインタープリタを書くのがお勧め。
最初は電卓とか、初期設定ファイル用のパーサからかな。

136 :デフォルトの名無しさん:04/06/13 22:11
>>135
ありがとうございまつ。
やっぱりpythonからでつか?

がんがってみまつ。

137 :デフォルトの名無しさん:04/06/13 22:17
>>136
インタプリタ「を」書く。
python用のインタプリタを書くつもりなら別にいいけど。

138 :デフォルトの名無しさん:04/06/13 22:25
とりあえずCやっとかないと、カーネルソースすら読めねぇって。

139 :デフォルトの名無しさん:04/06/13 22:28
scheme のインタプリタが楽だよね。

140 :デフォルトの名無しさん:04/06/13 23:32
ワシらの若い頃は「おまえ scheme の処理系も書けないの、プ」とか「おまえ
エディタも書けないの、プ」とか「おまえ版管理ソフトも書けないの、プ」と
か言われたもんじゃ…。

パーサ、メモリ管理、ファイル処理、文字列検索、文字列比較、か。なるほど。


141 :デフォルトの名無しさん:04/06/14 08:49
>>137-140
ありがとうございまつ

142 :デフォルトの名無しさん:04/06/14 08:59
最近はみんなマルチメディア方面に一所懸命で
記号処理ツールの作成はやらないのではないかな。

143 :デフォルトの名無しさん:04/06/14 16:11
>>110でsetitimerの時間がずれるって書いたけど単に別の部分のalarmと競合して
itimerが無効になってただけだった・・
どうりで指定した時間になっても終わらないはずだ。
とりあえずkillallでなんとか思い通りに止まってくれました。

144 :デフォルトの名無しさん:04/06/14 23:35
>>143
sleepとalarmは競合する。

145 :デフォルトの名無しさん:04/06/14 23:45
競合すると言うか、sleep がシグナル (SIGALARM) で割り込まれるだけだと思うが。

146 :デフォルトの名無しさん:04/06/15 03:42
>>142
マルチメディア方面と言っても、
JPEGやMPEG1のdecodingなど>>140とたいして変わりないよね。

147 :デフォルトの名無しさん:04/06/16 01:30
UNIXでマルチメディアだ、とか聞くと笑っちゃうよ。

だってうんこsh画面のイメージが強すぎて、
こんなんでマルチメディアできんの??
とか先入観入って思わずSGIとかの存在忘れちゃうしよ。
ウププ

ところで本当にできてるの?
UNIXでマルチメディア(禿藁

148 :デフォルトの名無しさん:04/06/16 01:31
できているよ。
真のマルチメディアはUNIXにあり

149 :デフォルトの名無しさん:04/06/16 01:34
ほんとに?(藁
だってうんこshが

150 :デフォルトの名無しさん:04/06/16 01:35
>>148
相手すんなよ。

151 :デフォルトの名無しさん:04/06/16 01:37
ていうかさ、うんこsh使ってる人って、
マルチメディアが何だかわかってる?(藁
絶対わかってないよね。
コワー(藁

152 :デフォルトの名無しさん:04/06/16 09:27
マルチメディア?
扱うデータ形式の操作やとりまわしが面倒なだけなような
だれか他の特質を回答希望

>>151
だれならわかっているかを回答よろしく


153 :デフォルトの名無しさん:04/06/16 12:55
>>151
先生!
「マルチメディア」って分かりません。
マルチメディアってなんですか?


154 :デフォルトの名無しさん:04/06/16 16:41
○血メディア

155 :デフォルトの名無しさん:04/06/17 03:08
マルチメディアという term が相当古い感じはするけど、グラフィックやるにも X じゃ
オーバーヘッドが大きそうな気はする。SGI が頑張っていた頃はそうでもなかったのかな?
サウンド関連は知らない。

156 :デフォルトの名無しさん:04/06/17 09:24
Macはそこそこがんばってる。
糞重いけど。

157 :デフォルトの名無しさん:04/06/17 09:44
>>155
> オーバーヘッドが大きそうな気はする。

想像で言うなよ。お前知識(というか伝聞)が古すぎだよ。


158 :デフォルトの名無しさん:04/06/17 09:47
>>156
一般利用者はMac OS Xでいいだろうけど、
この板のメインキャストであるプログラマから観たら、
糞APIと糞言語のシステムだな。

159 :デフォルトの名無しさん:04/06/17 11:13
普通にtelnetで入ってgccとか使ってる分にはその辺のUNIXと変わらない。

160 :デフォルトの名無しさん:04/06/17 11:54


161 :デフォルトの名無しさん:04/06/17 20:08
>>157
今の X は、Windows みたいなカーネル空間に一部突っ込んじゃう様な実装に比べても、
十分な速度が出てるって言ってます?

162 :デフォルトの名無しさん:04/06/17 20:34
>>161
きょうびのハードじゃ「カーネル空間に一部突っ込んじゃう」必要性はあんまりないのでは?
むしろ...


163 :デフォルトの名無しさん:04/06/17 20:45
俺のイメージね。

X: ウィジェット毎にソケット作るよ。
Win: GDI はカーネルモジュールだよ。

164 :デフォルトの名無しさん:04/06/17 22:28
Xももはやビットマップ転送にしか使われてないねぇ
それならもうカーネルの近くに入ってもいいと思うよ

165 :デフォルトの名無しさん:04/06/18 03:51
Xはうんこだろ

166 :デフォルトの名無しさん:04/06/18 06:57
>>161>>163
DRI知らないでX11語るアフォな人々?
http://dri.sourceforge.net

167 :デフォルトの名無しさん:04/06/18 14:00
>>166
くだらない煽りはUNIX板でやってくれないかな?

168 :デフォルトの名無しさん:04/06/18 14:29
XがWindowsのように早いウィンドウシステムだったら誰も文句は言わないだろう。

169 :デフォルトの名無しさん:04/06/18 14:41
Xのほうが早いですよ

170 :デフォルトの名無しさん:04/06/18 14:49
>>168
どういう環境,用途で使うからXの速度に不満が出るの?
ちょっと興味がある.
ソフト,ハードとも教えてみてよ.


171 :デフォルトの名無しさん:04/06/18 14:51
Xが遅いというとどうしてこうも必死な反応が返って来るんだろうか。

172 :デフォルトの名無しさん:04/06/18 15:01
>>171
Xに依存してるものは多いですからね.


173 :デフォルトの名無しさん:04/06/18 15:26
Xは速いよ。角度とか。

174 :デフォルトの名無しさん:04/06/18 18:45
じゃーねー。
『Xlibがとにかく遅い!!』
『Xlibのオーバヘッドがでかくて我慢ならん!!!』


175 :デフォルトの名無しさん:04/06/18 18:47
自分で書き直せば?

176 :デフォルトの名無しさん:04/06/18 18:55
>>174
別に特殊な用途ではないのね?
ハードは何使ってるの?
OSは?


177 :デフォルトの名無しさん:04/06/18 20:41
たかが描画命令程度でプロセス間通信するなんてオーバーヘッド多すぎ。
バカじゃねえの。

178 :デフォルトの名無しさん:04/06/18 21:09
そういう設計なんだからしょーがないじゃん

179 :デフォルトの名無しさん:04/06/18 21:22
>>177
それが律速段階になってるのは確認したの?

177は利用している環境(ハード,ソフト)が特殊なのか,
それともそれを感じる主観が特殊なのか?


180 :デフォルトの名無しさん:04/06/18 21:31
バカ発見

181 :デフォルトの名無しさん:04/06/18 21:33
(´-`).。oO(>>177は「律速段階」をググってる段階だと思うな)

182 :179:04/06/18 21:50
>>179
もう一個あった.
私の主観が特殊って可能性もあるか....

まぁいいや.環境を晒してみてよ.


183 :デフォルトの名無しさん:04/06/18 22:43
[現在このスレは、ほのかに荒れています。しばらく、そのままの状態でお待ち下さい。]

184 :デフォルトの名無しさん:04/06/18 23:39
Xを使わずにすむならそうしたいねぇ
あんな古い設計はそろそろおさらばしたいところ

185 :デフォルトの名無しさん:04/06/18 23:42
GnuFXが必要だろ

186 :デフォルトの名無しさん:04/06/19 09:37
(´-`).。oO(Longhornでグラフィック関係がXやNT3.51のようにユーザモードに戻るの知らないのだろうか…)
(´-`).。oO(CSRSS.exeが明記されていないが、それ以外はNT3.51と全く同じ構造になるのよね)
(´-`).。oO(http://www.itmedia.co.jp/news/0310/29/l_avalon.jpg)

187 :デフォルトの名無しさん:04/06/19 09:45
Longhorn駄目じゃん。こりゃ当分デスクトップはWindows2000のままだな。

188 :デフォルトの名無しさん:04/06/19 10:00
プロセス間通信と区別が付いてない馬鹿発見

189 :デフォルトの名無しさん:04/06/19 10:04
>>188
何が違うの?

190 :デフォルトの名無しさん:04/06/19 10:24
早く教えれ

191 :186:04/06/19 10:34
>>188
誰が何とプロセス間通信の区別が付いていないのかわからないが、

LonghornでCSRSS.exeを使うと明記されていないので、NT3.51やXのようにCSRSS.exeやXサーバ
とプロセス間通信する形でグラフィック関係を実装するとはっきり明記されているわけではないん
だけど、ぱっと見ではNT3.51に戻るようにしか見えないのよね。

Window ManagerもNT3.51と同じようにユーザモードに戻るので、少なくともWindowの処理には
Window Managerとのプロセス間通信が必要になるし、通常の描画処理にしても、CSRSS.exeや
win32k.sysなど単一のコンポーネントが管理するモデルを変更するとは思えない。

192 :デフォルトの名無しさん:04/06/19 10:42
> 少なくともWindowの処理には
> Window Managerとのプロセス間通信が必要になるし

馬鹿発見

193 :デフォルトの名無しさん:04/06/19 10:43
粘着うぜえ
スレ違いだろ


194 :デフォルトの名無しさん:04/06/19 10:50
>>192
早く教えれ

195 :186:04/06/19 11:12
>>192
ああ、そうか。必ずしもWindow Managerをプロセスとして実装する必要はないのか。

でも、その場合でも、画面という単一のリソースを複数のアプリからアクセスすることになる以上、
画面に対する排他制御が必要になり、そのため画面の一部になるWindowの管理や描画には、アプリ
ケーション間でプロセス間通信してWindowのロック等をすることになるから、どっかでプロセス間
通信が必要になることには変わりない。

それに、Windowの管理のためのリソースは排他制御のため他のアプリからアクセスできる場所にある
必要があり、かつその場所が独立したWindow Managerユーザプロセス内部ではないとすると、カー
ネルがリソースを保持することになり、Window Managerがユーザモードに移ることと矛盾するぞ。

プロセス間通信なしにユーザモードだけでどうやってWindow管理できるか教えてくれ。アフォなんで
わからん。

196 :デフォルトの名無しさん:04/06/19 11:38
TCP/IPはリソース共有してるが、使うのにプロセス間通信してないぞ。

197 :デフォルトの名無しさん:04/06/19 11:39


198 :デフォルトの名無しさん:04/06/19 11:40
> カーネルがリソースを保持することになり、Window Managerが
> ユーザモードに移ることと矛盾するぞ。

(´-`).。oO(Window Managerがユーザモードに移るって誰が言ったんだろう)

199 :デフォルトの名無しさん:04/06/19 11:45
>>198
仮定の話だよ。池沼は話の流れが読めないのかそうか。

200 :デフォルトの名無しさん:04/06/19 11:46
いいから

>プロセス間通信と区別が付いてない馬鹿発見

これについて教えれ

201 :デフォルトの名無しさん:04/06/19 11:54
>>198
>>186
> (´-`).。oO(http://www.itmedia.co.jp/news/0310/29/l_avalon.jpg)
をよく見れ。

NT3.51とNT4.0/2000は
http://www.atmarkit.co.jp/fwin2k/insiderseye/watchdd002/whatwdm1-1.html

特にNT4.0の
http://www.atmarkit.co.jp/fwin2k/insiderseye/watchdd002/winnt4arch.gif

202 :デフォルトの名無しさん:04/06/19 11:56
スレ違いというのが分からないのか・・・

203 :デフォルトの名無しさん:04/06/19 13:02
最後にXの話に戻れば許すからたまには実のある話聞かせろ知ったか連中が

204 :デフォルトの名無しさん:04/06/19 16:15
やっぱマイクロカーネル&マルチOSサーバ最強だよな。
またHurd使い始めるかな。

205 :: デフォルトの名無しさん :04/06/19 19:09
おまえら本とに亜ふぉだな(w
まあおれはBSD使ってるから大丈夫だけどな。

206 :デフォルトの名無しさん:04/06/19 19:12
何が大丈夫なんだ?w

207 :デフォルトの名無しさん:04/06/19 22:28
>>205
おまえもか。おれもさ。
お互い勝ち組でいこうや

208 :デフォルトの名無しさん:04/06/19 23:39
OSぐらい選り好みせずになんでもバリバリ使え。

209 :デフォルトの名無しさん:04/06/20 04:45
Linuxを使っている俺は負け組か・・・

210 :デフォルトの名無しさん:04/06/21 11:04
LinuxでSIGSEGVやSIGFPEなどのエラーシグナルが発生した場合に、C++の例外を送出したいのですが、どうしたらいいでしょう?
シグナルハンドラの中から例外を出してもうまくいきませんでした。。。

211 :デフォルトの名無しさん:04/06/21 11:09
出来ません。

212 :デフォルトの名無しさん:04/06/21 11:40
>>210
>LinuxでSIGSEGVやSIGFPEなどのエラーシグナルが発生した場合に、
そのシグナルを出すことがむしろ問題だぞ。
バグのあるソースを修正しろYO。

213 :デフォルトの名無しさん:04/06/21 16:14
>>204-205
そうか、マイクロカーネルな BSD であらせられる Mac OS X 様は最高か!

214 :211:04/06/21 16:59
>>212
そう言う問題じゃないですYO!

215 :デフォルトの名無しさん:04/06/21 23:23
>>210
static SignalCode = 0;

static void Handler(int Code){
  SignalCode = Code;
}

sigaction(SIGSEGV, Handler の登録);
sigaction(SIGFPE, Handler の登録);
try {
  /* なんかの処理 */
  if(SignalCode != 0) throw SignalCode;
  /* なんかの処理 */
  if(SignalCode != 0) throw SignalCode;
  /* なんかの処理 */
  if(SignalCode != 0) throw SignalCode;
} catch(int Code){
  /* シグナルの処理 */
}

とやるぐらいしか思いつかん。

>>212
SIGSEGV や SIGFPE の原因が必ずしもソースにあるわけじゃないぞ。

216 :デフォルトの名無しさん:04/06/22 09:34
何故そんな不気味なSIGNALをキャッチしたいのか、むしろ仕様を疑うぞ。
それとも、そのアプリがうまく動く自身が無いのか?

217 :デフォルトの名無しさん:04/06/22 12:44
>>216
「SIGSEGV や SIGFPE が発生した場合には、C++の例外を投げる」
という仕様を与えられて数値計算か何かのライブラリを作ってるんじゃないの?

218 :デフォルトの名無しさん:04/06/22 12:59
いずれにしても変な仕様。

219 :デフォルトの名無しさん:04/06/22 14:01


220 :デフォルトの名無しさん:04/06/23 00:19
C99 floating point rounding and exception handling は知ってるのかな?
feclearexcept, fegetexceptflag, feraiseexcept, fesetexceptflag, fetestexcept

221 :デフォルトの名無しさん:04/06/23 12:03
SIGSEGVは?

222 :デフォルトの名無しさん:04/06/23 12:05
>>221
落ちてやるのがみんなのためかと。

223 :デフォルトの名無しさん:04/06/26 19:24
UNIX のソースを開いたとき CL という
小さい文字が改行の位置に出てくるのですが・・・
これは何なのでしょう

224 :デフォルトの名無しさん:04/06/26 19:56
改行コード

225 :デフォルトの名無しさん:04/06/28 12:26
改行じゃなく改頁でしょ。


226 :デフォルトの名無しさん:04/06/28 12:34
>>223
印刷時にそのコード(CL)で改ページするって奴ね。

227 :デフォルトの名無しさん:04/06/28 13:25
C-Lか? (FF, '\f')

http://www.google.com/search?q=foldoc+form+feed&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8

228 :デフォルトの名無しさん:04/06/28 21:48
CR+LF の C と L を取って CL って事は無いかな?
ローカルに持ってくる時に改行コードが変わったとか。

何にしてもエディタ依存の様な。


229 :デフォルトの名無しさん:04/06/28 23:21
>>226
>>223の話を聞くと1行ごとに改ページが入っていそうな。

230 :デフォルトの名無しさん:04/06/29 01:22
>>223
使ったエディタと読んだソースを書け。

231 :デフォルトの名無しさん:04/06/29 09:54
うわ!改頁コードを知らない初心者がこんなにいるとは...

232 :デフォルトの名無しさん:04/06/29 10:10
「改頁コード」なんか知らん。
0x0C の事なら書式送り (form feed) だし、FF とか ^L と表すからね。

233 :デフォルトの名無しさん:04/06/29 11:03
書式送りは改頁に使うとは決められていないから、一行毎に入っていても
エディタによっては普通に見られるね。

234 :233:04/06/29 11:11
見られるってのは読めるって意味ね。

>>223
元は tar.gz でアーカイブされたファイルじゃなかった?

235 :デフォルトの名無しさん:04/06/29 21:06
COBOLERはみんなそういうワ

236 :デフォルトの名無しさん:04/06/29 21:33
>>232
> 「改頁コード」なんか知らん。

改頁コード: 65件
改ページコード: 219件

書式送り: 109件

237 :232:04/06/29 21:59
>>236
ホントだ。プリンタ由来の単語みたいだね。JIS 的にも「改頁」なのかな。
プレーンテキストでは FF の意味は決まってなかった気がするけど。

238 :デフォルトの名無しさん:04/06/29 22:12
つぅか使わん。

239 :デフォルトの名無しさん:04/06/30 01:32
/::::::::::::::: ..:::::::::::::::i、::::::::::::::::::::'、':,.    /  ヽ
  /::::::::::: ....:::::::::::::::::::::i:::!`、:ト、::::::::::::i i!   /     i >>238
 i   ...::::::|'、ヽ;::::::::::::::|,!:!__リ,,'iヽ::l''、:'、  /     /
 | ..::::::::;:::i!:i ヾ:、ヽ:::::::::| リ , -─ リ i;il:ヽ, i    /    あはははは〜
 l:::::::::::::::i',i ':i ,メ、 \;:l '゙    `、 !::::/l ...::::::/``ヽ
 l::ヽ:::::ヽ:i,レ',.゙-‐''''         ',/'/..::::::::::/    l'ヽ;、  
  i:::::>、:ヾ,' /     _,.. -‐'ヾi    ,レ'::::::::::;r':..   /  i_\
  i:::i. `'‐,ゝ    i"     '! ,.‐''" :::::::::::i゙::::::::.../.  ノ 'i    
   !::\ `ヽ    ':,     l{   ..:::::/::L,. ‐'":::::;/  !
   l::::::::`''‐r\    ヽ.,__,.ノィ'‐-‐''"'ォ‐--,゙弋''''"::::::;.ノ
   |::::::::;ィ:::}、 ``'''─--、-‐ニ┤ ___ハ,`''ーヽ-'=‐''"



240 :デフォルトの名無しさん:04/06/30 16:59
/::::::::::::::: ..:::::::::::::::i、::::::::::::::::::::'、':,.    /  ヽ
  /::::::::::: ....:::::::::::::::::::::i:::!`、:ト、::::::::::::i i!   /     i >>232
 i   ...::::::|'、ヽ;::::::::::::::|,!:!__リ,,'iヽ::l''、:'、  /     /
 | ..::::::::;:::i!:i ヾ:、ヽ:::::::::| リ , -─ リ i;il:ヽ, i    /    あはははは〜
 l:::::::::::::::i',i ':i ,メ、 \;:l '゙    `、 !::::/l ...::::::/``ヽ
 l::ヽ:::::ヽ:i,レ',.゙-‐''''         ',/'/..::::::::::/    l'ヽ;、  
  i:::::>、:ヾ,' /     _,.. -‐'ヾi    ,レ'::::::::::;r':..   /  i_\
  i:::i. `'‐,ゝ    i"     '! ,.‐''" :::::::::::i゙::::::::.../.  ノ 'i    
   !::\ `ヽ    ':,     l{   ..:::::/::L,. ‐'":::::;/  !
   l::::::::`''‐r\    ヽ.,__,.ノィ'‐-‐''"'ォ‐--,゙弋''''"::::::;.ノ
   |::::::::;ィ:::}、 ``'''─--、-‐ニ┤ ___ハ,`''ーヽ-'=‐''"


241 :デフォルトの名無しさん:04/06/30 23:14
>>239-240

今年の流行語大賞はコントロールブレイクとか本気で思ってる人ですか?

242 :デフォルトの名無しさん:04/07/04 12:19
画像ソフトを作成しているのですが、
libpngを使い、ダイナミックリンクで読み込んでいます。

これをlibpngが導入されていない環境では、
使用せず、導入されている環境では使用するような方法はあるのでしょうか?
スタティックリンクは使いたくないので・・・。

すいませんが、お願いします。

243 :デフォルトの名無しさん:04/07/04 12:28
>>242
コンパイル時だったら
$ ./configure <---------
$ make
# make install

実行時の判断は??? >>243


244 :デフォルトの名無しさん:04/07/04 12:29
-実行時の判断は??? >>243
+実行時の判断は??? >>245


245 :デフォルトの名無しさん:04/07/04 12:50
#include <stdio.h>


246 :デフォルトの名無しさん:04/07/04 16:11
dlopen()?


247 :デフォルトの名無しさん:04/07/04 18:08
>>246
へー,面白そう.


248 :デフォルトの名無しさん:04/07/06 22:06
実行時の判断て,libcのバージョン違ったらどうするんだ?
バイナリ配布なら,staticにリンクするべき。


249 :デフォルトの名無しさん:04/07/06 23:44
>>248
そんなに愉快にI/Fは変わらないので問題なしです。

250 :デフォルトの名無しさん:04/07/06 23:47
>>248
本題とはずれるけど、glibcではsymbol versioningが使えるらしい。
ttp://www.gnu.org/software/libc/FAQ.html#s-1.17


251 :デフォルトの名無しさん:04/07/07 07:42
signalの使い方がが良く見えないんで教えてください。

1. longjmp( )は、シグナルハンドラからの使用を考慮されている、
あるいは使用例としてよく出てくるんですが
実際、シグナルハンドラからのlongjmp( )は安全ですか?
というのは、3Cの関数あたりからシグナルが発生したときに
メモリリークやなにかの状態不一致など発生しないよう考慮されているんでしょうか?

たとえば、malloc( )の中でメモリブロックのチェインを組み替えている
途中でシグナル ->longjmp( ) ->組み換え中おメモリブロックは忘れ去られたまま
なんてことにはならないようになっているんでしょうか?


2. シグナルハンドラとそうでない部分との排他制御は
そうでない部分で、シグナルをマスクするだけで十分ですか?

3. シグナルハンドラが実行されているさいちゅうに
多重に呼び出されることはありますか?


252 :デフォルトの名無しさん:04/07/07 07:44
タイプミス。

s/組み換え中おメモリブロックは忘れ去られたまま/組み換え中のメモリブロックは忘れ去られたまま/

ごめんなさい。

253 :デフォルトの名無しさん:04/07/07 10:40
>>251
1.シグナル受信時は即時にハンドラを起動しない。
 malloc時はアトミックに処理するはず。
2.>シグナルハンドラとそうでない部分との排他制御は
 >そうでない部分で、シグナルをマスクするだけで十分ですか?
 言ってる意味がわからん。そうでない部分とは?
3.>シグナルハンドラが実行されているさいちゅうに
 >多重に呼び出されることはありますか?
 何が多重かわからんのだが、シグナルハンドラ処理時に同じシグナルを受けた場合は
 ブロックする。多重には実行されない。

RTFM

254 :デフォルトの名無しさん:04/07/07 10:56
遅レスだが、
>>210
>LinuxでSIGSEGVやSIGFPEなどのエラーシグナルが発生した場合に、C++の例外を送出したいのですが、どうしたらいいでしょう?
>シグナルハンドラの中から例外を出してもうまくいきませんでした。。。
もし、バグでメモリを破壊していてSIGSEGVになったらどうする?
その作りは、信号が赤信号であるのにそのまま突っ走るようなものだな。
いつか衝突するぞ。そして原因究明が困難なものになるだろう。

255 :デフォルトの名無しさん:04/07/07 12:00
>>251
> というのは、3Cの関数あたりからシグナルが発生したときに
> メモリリークやなにかの状態不一致など発生しないよう考慮されているんでしょうか?

それは君の仕事です。

> 2. シグナルハンドラとそうでない部分との排他制御は
> そうでない部分で、シグナルをマスクするだけで十分ですか?

シグナルに対する排他としては十分です。
ブロックされている間シグナルはプロセスに運ばれませんから。

> 3. シグナルハンドラが実行されているさいちゅうに
> 多重に呼び出されることはありますか?

UNIXによって方言があります。最近のは全部ブロックするはずですが。

256 :デフォルトの名無しさん:04/07/07 23:58
>>254
そう言ったらあるWindows鯖ソフトの作者にバカにされたよ。
そいつは嬉々として一般保護違反を隠しながら動く痛いソフトを神面して配布しているよ。

257 :デフォルトの名無しさん:04/07/08 00:05
しかし、>>254の言うのも間違っていると思うよ。

(一部の)signalには、異常報告の意味があるけど、
その時にC++の例外を投げて欲しいというのは、
ごく自然な要望だ。


258 :デフォルトの名無しさん:04/07/08 00:16
>>257
で、問題はそれを誰に投げるかって話だな。


259 :デフォルトの名無しさん:04/07/08 04:45
>>251
POSIX的にはlongjmp()はsignal maskの扱いについてunspecifiedなんで、
できることならsiglongjmp()を使っとけ。
ttp://www.opengroup.org/onlinepubs/009695399/functions/longjmp.html

あと、このページ、
ttp://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
特に下の方の async-signal-safe な関数の一覧も読んどけ。

260 :デフォルトの名無しさん:04/07/08 10:12
>>253
> malloc時はアトミックに処理するはず。

本当ですか?

261 :デフォルトの名無しさん:04/07/08 10:14
アトミックってなんですか?
ひょっとしてアトムの弟ですか?

262 :デフォルトの名無しさん:04/07/08 10:54
そりゃコバルト・・・は兄か。

263 :デフォルトの名無しさん:04/07/08 15:43
>>260
RTFS

264 :デフォルトの名無しさん:04/07/08 15:50
>>263
http://www.science.uva.nl/~mes/jargon/r/rtfs.html
これ?

265 :デフォルトの名無しさん:04/07/08 16:28
Read The Fucking Sourceウケタ

266 :デフォルトの名無しさん:04/07/08 20:39
Cで可変長のCSVを切り出すのは面倒。
なんかいいライブラリないの?

267 :デフォルトの名無しさん:04/07/08 20:41
strtok()を使ったり,strchr()で地道にやれか...。


268 :デフォルトの名無しさん:04/07/08 20:47
Cで簡単にできる文字列処理などない。

269 :デフォルトの名無しさん:04/07/08 20:54
Cで簡単にできる処理などない。

270 :デフォルトの名無しさん:04/07/08 20:56
>>266
C++だったらboost::tokenizerとかあるけど


271 :デフォルトの名無しさん:04/07/08 21:53
アトミックってたってどの次元でアトミックなのかが問題だろ。

1.スレッドに対してアトミックなのか?
2.シグナルに対してアトミックなのか?
3.プロセッサに対してアトミックなのか?

3ならば1,2を満たす。1と2は無関係。

ここで問題なのは2なんだが、mallocがアトミックなのは1じゃないのか?


272 :デフォルトの名無しさん:04/07/08 22:52
>>271
スレッドに対してアトミックでも嬉しくも何ともない予感。
別のスレッドが確保してるであろうメモリに非同期にアクセスしに行くなんて自殺行為な訳で。

とか煽りつつどんなメリットがあるのか聞いてみたいテスト。

273 :デフォルトの名無しさん:04/07/08 23:02
>>272
>>271 は、malloc() がスレッドセーフであろう、というようなことを言ってると思われ。
そうして、もちろんそうでなければ使い物にならない。

274 :271:04/07/08 23:16
>>272

>別のスレッドが確保してるであろうメモリに
>非同期にアクセスしに行くなんて自殺行為な訳で。
>とか煽りつつどんなメリットがあるのか聞いてみたいテスト。

では煽られつつ答えるテスト。

malloc( )はヒープというプロセスに1つ、スレッド間で共有された資源
の操作をする関数。

獲得以降がスレッド個別の資源だと仮定すると、
malloc( )は共有資源を個別資源にする関数。

そのためには共有資源への操作が必要。

だからアトミックである必要がある。
当然free( )も同様。

>別のスレッドが確保してるであろうメモリに
>非同期にアクセスしに行くなんて自殺行為な訳で。

非同期にアクセスしたら死ぬけど、
非同期にならんようにミューテックスとかあるんじゃないのか?


275 :デフォルトの名無しさん:04/07/08 23:19
ふと思ったけどアトミックと排他処理って同じもんなの?

いくら排他しても処理途中で割り込まれる要素があればそれはアトミックとは言えない気がします。

276 :271:04/07/08 23:30
>>275

いや俺も同じではないと思うが、
話を合わせている都合上、そうなってしまった。
すまん。


277 :デフォルトの名無しさん:04/07/08 23:36
LISPのアトムも分解できるわけだが

278 :デフォルトの名無しさん:04/07/08 23:38
ウランちゃんの衣服を分解・・・ハァハァ

279 :デフォルトの名無しさん:04/07/08 23:59
何か誤解されたわけだが

280 :デフォルトの名無しさん:04/07/09 01:13
排他することでアトミックであることを確保するんですよー

281 :デフォルトの名無しさん:04/07/09 02:31
用語の使い方って難しいね。
おそらく中途半端な知識を持ってる人が結構誤解するのかもね。

282 :デフォルトの名無しさん:04/07/09 05:25
>>251
> 1. longjmp( )は、シグナルハンドラからの使用を考慮されている、
> あるいは使用例としてよく出てくるんですが
> 実際、シグナルハンドラからのlongjmp( )は安全ですか?
ttp://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
より引用。
> In the presence of signals, all functions defined by this volume of
> IEEE Std 1003.1-2001 shall behave as defined when called from or
> interrupted by a signal-catching function, with a single exception:
> when a signal interrupts an unsafe function and the signal-catching
> function calls an unsafe function, the behavior is undefined.

で、malloc()もlongjmp()もsiglongjmp()もsignal unsafe。
よって、「malloc()中にシグナル発生 → シグナルハンドラ内でlongjmp()
(またはsiglongjmp())呼び出し」となった場合の動作は「undefined」。
実際にglibcのソースを眺めてみたが、シグナルに対して特別なことをやっては
いないみたいだから、メモリリークやデッドロックが発生する可能性があるな。

> 2. シグナルハンドラとそうでない部分との排他制御は
> そうでない部分で、シグナルをマスクするだけで十分ですか?
OK.

> 3. シグナルハンドラが実行されているさいちゅうに
> 多重に呼び出されることはありますか?
ここらへんについては、BSD由来のsignal()とSysV由来のsignal()とで
挙動が大きく違っていたが、新しいシグナル操作関数であるsigaction()では
そこら辺の混乱が解消されている。
ttp://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html
SA_NODEFERの項を見よ。

283 :282:04/07/09 05:31
ちなみに↓に書いてあるように、malloc()はthread-safeではある。
ttp://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
すなわち、複数のスレッドが同時にmalloc()を呼び出しても安全ということ。

284 :デフォルトの名無しさん:04/07/09 13:38
閑話休題:
割とメジャーなもので SIGSEGV をトラップしているものとしては、mpeglib なんかがある。
これは、MPEGデコーダの性質上

・入力データは外部から与えられるため、信用できない(変なデータって実は結構ある)
・デコード処理は高速性が求められるため、最も内側のループにはエラーチェックを入れにくい
 (実際のとこチェック不可でエラーが発生する箇所は、DCテーブルの再構築時がほとんどみたいです)
・エラーが発生したとき、止めるよりはちょっと画像が乱れるだけで動いてくれた方が(大抵は)うれしい
・ストリームを適当に先へ進めば、エラーをリカバリできるポイントが見つかる

から。
IA32 でいうところの 0:32 モデルじゃなくて、怪しげな操作をするときには 32:32 で
厳しくアクセス可能な範囲を限定したポインタが使えるとこういうとき便利っぽいですよね。

285 :デフォルトの名無しさん:04/07/09 14:39
>>284
もうしわけありません。
どうもSIGSEGVをトラップする利点がわかりません。
SIGSEGVがある特定の区間以外発生することは無いっていうことなのでしょうか?

286 :デフォルトの名無しさん:04/07/09 15:08
>>284
>IA32 でいうところの 0:32 モデルじゃなくて、怪しげな操作をするときには 32:32 で
>厳しくアクセス可能な範囲を限定したポインタが使えるとこういうとき便利っぽいですよね。
これってどういう意味なのでしょうか?

287 :デフォルトの名無しさん:04/07/09 19:51
>>286
ごめんなさい。16:32 の間違いでした。
セグメント(セレクタ)16bit, オフセット32ビットのポインタを使ったメモリアクセスのことです。

288 :デフォルトの名無しさん:04/07/09 19:54
>>285
既に 284 で4つ理由を書いています。
どれに同意できない(あるいはわからない)のですか?

289 :デフォルトの名無しさん:04/07/10 00:25
話は変わるが主婦が家庭裁判所で訴えられるってどういう状況?

290 :デフォルトの名無しさん:04/07/10 00:50
このスレ的にはUNIXプログラマと浮気した場合かな。

291 :デフォルトの名無しさん:04/07/10 03:53
つーか、Java VMとかでもJITコンパイラを搭載しているようなやつは
ぬるぽ^H^H^H NullPointerException を検出するために
SIGSEGVをトラップしているものが多い。
# もちろんSunのHotspot VMもそう。

292 :デフォルトの名無しさん:04/07/10 04:43
>>291
ガッ!!^H^H^H^H

293 :デフォルトの名無しさん:04/07/10 08:47
>>284
リカバリなんてできるんですか?

294 :デフォルトの名無しさん:04/07/10 08:52
>>284
>・入力データは外部から与えられるため、信用できない(変なデータって実は結構ある)
>・デコード処理は高速性が求められるため、最も内側のループにはエラーチェックを入れにくい
> (実際のとこチェック不可でエラーが発生する箇所は、DCテーブルの再構築時がほとんどみたいです)
>・エラーが発生したとき、止めるよりはちょっと画像が乱れるだけで動いてくれた方が(大抵は)うれしい
>・ストリームを適当に先へ進めば、エラーをリカバリできるポイントが見つかる
これはSIGSEGVになる可能性があるという作りだってことですか?
そもそもSIGSEGVにならないように作らなければならないと思っていたのですが。

295 :デフォルトの名無しさん:04/07/10 16:01
>>293-294
コードのこの範囲でSIGSEGVが発生する可能性があってそれはこうこうこういう状況で
その時はこうすればリカバリできるって完全に把握してSIGSEGVを受けとる場合がある
のよ。
普通のプログラムがバグなんかで予測してない挙動してSIGSEGVで落ちてるような状況
とは違う。
そういうプログラム書いてる時にバグ作りこんじゃうとどつぼにはまるけどね。

296 :デフォルトの名無しさん:04/07/10 17:54
・デコード処理は高速性が求められるため、最も内側のループにはエラーチェックを入れにくい
 (実際のとこチェック不可でエラーが発生する箇所は、DCテーブルの再構築時がほとんどみたいです)

↑こんなの絶対に使いたくねー!!

297 :デフォルトの名無しさん:04/07/10 18:17
冬ソナファンは民主党に投票しよう!  投稿者:わんこ 投稿日:2004/07/08 22:16 No.622
わたしはそれは在日韓国人に対する差別だと思うんです。
第二次大戦中の日本国民の韓国人に対する強制徴用、大量虐殺に始まり
今日での在日韓国人に対する差別。
その最たるものが在日韓国人に参政権がないことです。
日本人と同じく税金を払い義務を果たしているにもかかわらず、です。
ところが今回の参院選ではなんと民主党が在日韓国人に参政権を与えることを公約としています。
そこで我々冬ソナファンがヨン様の国、韓国の人々のために
立ち上がろうではないですか!!
冬ソナファンの力で民主党に政権を取らせ、在日韓国人の参政権獲得の手助けをしましょう!!
ヨン様のためにがんばろう!!!


298 :デフォルトの名無しさん:04/07/10 21:12
>>295
>コードのこの範囲でSIGSEGVが発生する可能性があってそれはこうこうこういう状況で
>その時はこうすればリカバリできるって完全に把握してSIGSEGVを受けとる場合がある
>のよ。
SIGSEGVが発生する可能性がわかっているならば、そうならないように作るべきでは?
それを知っていてあえてSIGSEGVを受信するような作りがよくわからないのです。
それが仕様であることはわかるんですけど、自分はその仕様に納得がいきません。

299 :デフォルトの名無しさん:04/07/10 21:38
>>298
そうならないように自前のチェック入れると処理が重たくなるということでは?

300 :デフォルトの名無しさん:04/07/10 21:45
それで間違えて書いちゃうようならSEGVになった方が
まだ運がよくて、スタック書きつぶしたりしたら下手
すりゃセキュリティホールだよな。

間違えて読んじゃうだけならぎりぎりセーフ?


301 :デフォルトの名無しさん:04/07/10 22:07
いやだから、
・SEGVが発生する条件は完全に特定できている(ゼロ除算とか)
・それを回避する方法も分かりきっているが、コストがかかるので避けたい
場合に使うんじゃないの。


302 :デフォルトの名無しさん:04/07/10 22:08
>>298
納得がいかなくてもやらざるを得ない、時の手段ってことでしょ。リミター解除して高速飛ばすようなもん。
これぞまさしく「素人にはお勧めできない」。

玄人にもお勧めできないけど。

303 :デフォルトの名無しさん:04/07/10 22:28
>>301
>・SEGVが発生する条件は完全に特定できている(ゼロ除算とか)
ゼロ除算ってSIGSEGVでしたっけ?
もしかして、SIGSEGVに限らずsignal全般ってことを言いたいのでしょうか?

304 :デフォルトの名無しさん:04/07/10 22:35
>>299
>そうならないように自前のチェック入れると処理が重たくなるということでは?
高速化の為にSIGSEGVをあえてするか堅牢性をあげるためにセキュリティ重視をするかって言われたら、
自分は後者を選ぶ。

305 :デフォルトの名無しさん:04/07/10 22:38
高速化の為にあえてSIGSEGVなプログラム書くこと自体が理解できない。

306 :デフォルトの名無しさん:04/07/10 23:07
>>305
激しく同意。
mpeglibという名前からしてライブラリなんだろうけど、絶対に使いたくないな。

307 :デフォルトの名無しさん:04/07/10 23:09
>>306
いや、使うところ違うし。

308 :デフォルトの名無しさん:04/07/10 23:13
なんだプラグインか。

309 :デフォルトの名無しさん:04/07/10 23:19
セキュリティはどうだっていいんだが(OSごとセキュアにすりゃいいという話もあるし)、
結局環境依存では。

310 :デフォルトの名無しさん:04/07/10 23:37
ネットワーク共有メモリの実装にSEGVとメモリ保護使った書き込み検出を
してるライブラリが有って感心した記憶がある。変則的な手段だとは思う
けど、忌み嫌うほどでも無いと思う。

311 :デフォルトの名無しさん:04/07/10 23:47
Garbage Collection でも使ってたりするね。

312 :デフォルトの名無しさん:04/07/10 23:50
>>310
MS Windowsでも、その汚いけれども高速な手段を結構使ってるらしいですね。

313 :デフォルトの名無しさん:04/07/10 23:52
>>309
ようするに、「動けばいいや」ってことですか?
であるならば、もう何も言うまい。

314 :デフォルトの名無しさん:04/07/10 23:56
でもさー、signalってprocess globalなんだよなぁ
unixはそこがダサい

315 :デフォルトの名無しさん:04/07/11 00:10
>>313
mpegのデコードの話だろ?
テーブル引くのに入力をチェックしないってだけじゃねーの?
不正な入力なら絵が壊れてもいいって割り切りでしょ。不正ならどうせ壊れるんだし。

316 :デフォルトの名無しさん:04/07/11 00:48
>>314
プログラムの終了には全スレッドにシグナルを投げる必要がある?


317 :デフォルトの名無しさん:04/07/11 00:49
>>314
process globalな割り込みが無いほうが困るのでは

318 :デフォルトの名無しさん:04/07/11 04:45
ん、グローバル変数だって言いたいのか?
たしかにシグナルはグローバルな設定だが・・・

319 :名無しさん@そうだ選挙に行こう:04/07/11 09:02
>>318
取りあえず晒しage

320 :名無しさん@そうだ選挙に行こう:04/07/11 09:10
フリーのOSで鯖を作るならkqueueが最高?

321 :名無しさん@そうだ選挙に行こう:04/07/11 09:14
>>320
?


322 :名無しさん@そうだ選挙に行こう:04/07/11 10:33
>>314
posix realtime extension

ちなみに昔null accessをSIGSEGVのsignal handlerで処理している
Lisp処理系があった。まあ別に速くはなってないと思うが。

323 :名無しさん@そうだ選挙に行こう:04/07/11 10:45
>>322
シグナルハンドラではグローバルなフラグを立てる感じ?



324 :名無しさん@そうだ選挙に行こう:04/07/11 10:55
>>320
OS毎に非ポータブルなハイパフォーマンスAPIがあるからそれ使え。
それがkqueueとは限らない。

325 :名無しさん@そうだ選挙に行こう:04/07/11 11:04
>>318
ライブラリAとライブラリBがsignalの奪い合いをする可能性がある、ってこと?
まああんまり気にしたことはないけど。

ああ、JavaでJNI使うときに一度ハマったねぇ

326 :名無しさん@そうだ選挙に行こう:04/07/11 11:13
>>325
て言うかシグナルをトラップするようなライブラリ好んで使うなと。

327 :名無しさん@そうだ選挙に行こう:04/07/11 11:44
>>323
いや、longjmpしてLispの(throw ...)へ突入。

328 :名無しさん@そうだ選挙に行こう:04/07/11 11:44
あ、(throw 'ぬるぽ)って書くべきだった?

329 :名無しさん@そうだ選挙に行こう:04/07/11 12:13
>>327
こうなると構造化もへったくれもないですな。
C++とかなら舜殺しそう。。。

330 :251:04/07/11 13:21
251でsignalハンドラからのlongjmpについて
質問したものです。

回答してくださったみなさま、ありがとうございます。
参考にさせていただきます。

特に、>>282さんの回答は根拠もしめされてまして
大変なっとくいくものでした。
ありがとうございました。


331 :魔方陣:04/07/11 16:35
学校の課題で魔方陣が出ました。でも全く説明がなくて・・・。

c 氏名 日付
   program pr2

integer a,i,j,k,l
parameter(n=3) !n は奇数
    dimension a(n,n)

print '(1x,a,i2)','pr2 魔方陣 n=',n
print *,'学生番号 氏名’
  
   do k=0,n-1
do l=0,n-1
i=(k+l)*2+(n+1)/2+2
j=l-k+(3*n+1)/2
a(mod((i-1),n)+1,mod((j-1),n+1)=n*k+l+1
end do
end do

do i=1,n
print '(9i5)', (a(i,j), j=1,n)
end do
end  
     
これは3×3で、課題はこれを9×9で計算して提出しろ、というものなんですが、
どこをどう変えればいいのかわかりません。
助けてください。 

332 :名無しさん@そうだ選挙に行こう:04/07/11 17:32
宿題は宿題スレへ

333 :名無しさん@そうだ選挙に行こう:04/07/11 18:34
>>314
Win32だとSEHがありますからね。
あれはtry - catch - finallyのセマンティクスで使えるから
ものすごく楽だし美しい

まあスタック巻き戻しの際にお掃除とかしてくれるわけじゃないから
C++ではいまいち使い物にならないけど

334 :名無しさん@そうだ選挙に行こう:04/07/11 18:56
>>333
C++では普通に使用禁止です。

335 :デフォルトの名無しさん:04/07/12 12:27
>>300あたりの人
喪前らが普通に使っている JPEG ライブラリ、MP3 ライブラリ、MPEGデコードライブラリの
大半はトンでもない不正データを食わせると sigsegv 起こしますよ。

んで、たかだか「入力ファイルが変」ってだけでバキバキ落ちる画像・動画再生プログラムは
ユーザに受け入れられませんよ。

336 :デフォルトの名無しさん:04/07/12 16:25
> 大半はトンでもない不正データを食わせると sigsegv 起こしますよ。

それが検証できるデータはありますか?

337 :デフォルトの名無しさん:04/07/12 16:34
あるよ

338 :デフォルトの名無しさん:04/07/12 18:23
UNIXプログラマになるには、libcのソースコードを暗記しないとダメなんですか?
UNIXの世界で有名なミスターtheo氏がそのようなことを言ってましたが。

339 :デフォルトの名無しさん:04/07/12 18:37
>>338
は?暗記してないの?

340 :デフォルトの名無しさん:04/07/12 18:56
アン肝なにも俺が書いたわけだが

341 :デフォルトの名無しさん:04/07/12 18:56
>>339
してるんですか?

342 :デフォルトの名無しさん:04/07/12 21:18
gccのソースを暗記しよう

暗記パンとか使って

343 :デフォルトの名無しさん:04/07/12 21:21
なんだその暗記パンって

344 :デフォルトの名無しさん:04/07/12 21:28
>>343
忘れてくれ・・

世代の違い?
ドラえもん 暗記パン
あたりで検索してみて

345 : :04/07/12 23:49
>>341
当然だろ。

346 :デフォルトの名無しさん:04/07/12 23:51
>>344
最後は食べ過ぎたのび太が自爆するんだっけか?

エネルギーを吸収する敵にはキャパ以上のエネルギーを叩き込んで自己崩壊を待つ。
昔のアニメの定石ですな・・・。


347 :デフォルトの名無しさん:04/07/12 23:53
668 :デフォルトの名無しさん :04/07/12 22:28
rm -f calculation.o
gcc -g-c ship.h -lm
gcc:Compilation of header
file requested
make:***[calculation]
Error1

と出力されます.
今日初めてwindows環境でUNIXを使うのですが、これの解決策を教えて下さいませんか.
お願い致します.
デスクトップ上の問題なのでしょうか?

348 :デフォルトの名無しさん:04/07/13 00:01
誰か翻訳コンニャクを

349 :デフォルトの名無しさん:04/07/13 17:29
>>347 の今後の為にも、答えない方がいいのかな…

350 :デフォルトの名無しさん:04/07/13 17:46
>>349
http://pc5.2ch.net/test/read.cgi/tech/1058134693/286
http://pc5.2ch.net/test/read.cgi/unix/1086622860/207

351 :デフォルトの名無しさん:04/07/13 21:05
スティーブンスの詳解UNIXプログラミングすげーなコレ!!!
かなり高価だけど、真剣に読み進めてプログラミングを繰り返していくと
技術が腕に染み込んでいくのがわかる。

352 :デフォルトの名無しさん:04/07/13 22:01
怖くて読めないな。
うわ〜染み込んでる〜。

353 :デフォルトの名無しさん:04/07/13 22:44
頭には浸みないのか。

354 :デフォルトの名無しさん:04/07/14 00:39
351は脳まで筋肉でできているような奴だから。

355 :デフォルトの名無しさん:04/07/14 01:00
>>354
少し位筋肉がないとモテんぞ。

356 :デフォルトの名無しさん:04/07/14 01:53
>>351はまじめないいレスじゃないか。いぢめるなよ。

357 :デフォルトの名無しさん:04/07/14 02:12
実際スティーブンスの本は素晴らしいよね。
この人のネットワークプログラミングの本は、
今でも漏れのバイブルです。

358 :デフォルトの名無しさん:04/07/14 03:50
日本人でもスティーブンスくらいドキュメンテーション能力のある人いないかね。


359 :デフォルトの名無しさん:04/07/14 08:34
スティーブンスの本はUNIXの歴史が詰まってるところがよいわけで、
単にUNIXに詳しいだけの人がああいう本を書けるのかどうか。

360 :デフォルトの名無しさん:04/07/14 23:43
スティーブンス氏は訴追の対象です。

361 :デフォルトの名無しさん:04/07/15 18:22
cp パス パス/ファイル2> /dev/null
上のコマンドの>と/dev/null
の意味は何ですか?。

362 :デフォルトの名無しさん:04/07/15 18:28
>>361
Linux板のくだ質逝け

363 :デフォルトの名無しさん:04/07/15 20:26
>>361
環境と言語くらい書け。

364 :デフォルトの名無しさん:04/07/15 21:01
cpってエラー以外なんか出力したっけ?

365 :デフォルトの名無しさん:04/07/15 21:10
0個のファイルをコピーしました

366 :デフォルトの名無しさん:04/07/15 21:12
「ファイル2」の2は、実は標準エラーの2というオチに1メセタ。

367 :デフォルトの名無しさん:04/07/15 23:13
>>366
そうだと思うが、書いた本人が判って無いと思う。



368 :デフォルトの名無しさん:04/07/15 23:24
>>364
上書き確認とか。

369 :デフォルトの名無しさん:04/07/15 23:51
>>368
No such file or directory
Permission denied
とか、いろいろ。



370 :デフォルトの名無しさん:04/07/16 00:18
>>369
cpって エ ラ ー 以 外 なんか出力したっけ?


371 :デフォルトの名無しさん:04/07/16 01:08
俺のcpは元旦に「あけましておめでとうございます」って言うよ

372 :デフォルトの名無しさん:04/07/16 04:15
cpに「できちゃったみたい」って言われたときはどうしようかと思ったよ

373 :デフォルトの名無しさん:04/07/16 10:39
>>372
rm -rf

374 :デフォルトの名無しさん:04/07/16 10:47
fork() して exec() する前ならまだ間に合う。kill しちゃいな。


375 :デフォルトの名無しさん:04/07/16 19:22
ここは家庭不和なシェルスクリプトですね

376 :デフォルトの名無しさん:04/07/16 22:47
>>374
親を殺して彼女は悪魔となりました。

377 :デフォルトの名無しさん:04/07/17 01:49
winのようにspawnして産み捨て

378 :デフォルトの名無しさん:04/07/20 00:40
でも、よく考えたら親が子が死ぬのを待つなんて非現実的だよな。(w
親の方が長く生き続けるっていう概念なのかな。
man 2 wait
まぁ、そもそも人間社会にあてはめること自体がおかしいのだけどね。

379 :デフォルトの名無しさん:04/07/20 01:16
親が見捨てるとゾンビになるし

380 :デフォルトの名無しさん:04/07/20 05:34
そりゃ正しくないような。unixは暗黒の世界なので死ぬと必ずzombieになる。
waitで正しく看取られて初めて成仏する。
親なき場合は神の子initが月に代わって成敗する。


381 :デフォルトの名無しさん:04/07/20 06:04
成敗じゃねえだろうよ。

382 :デフォルトの名無しさん:04/07/20 07:04
じゃあ、月に代わっておしおきですか?

383 :デフォルトの名無しさん:04/07/20 07:51
forkって子供を産むというよりも単細胞生物の分裂みたいだよね。

384 :デフォルトの名無しさん:04/07/20 07:57
メモリをwriteするごとに成長するプラナリア

385 :デフォルトの名無しさん:04/07/20 08:22
んー、いまいちか。

386 :デフォルトの名無しさん:04/07/20 10:11
印刷に関して教えてください。
unixとwindows双方から印刷できるようにLPDを使用しているのですが、
windows から lpr にて印刷する場合portなどを指定しなければならず、
パソコンをあまり使用しない人には使いにくいので、LAN接続されてい
るプリンタ一覧を表示したいのですが、プリンタ情報を取得するAPIな
どありますか?

387 :デフォルトの名無しさん:04/07/20 12:41
unixと言ってもいろいろあるからなあ
商用ならサポートへ
フリーのやつなら環境書け


388 :デフォルトの名無しさん:04/07/20 12:42
んー、場合によってはSNMPかなあ?

389 :デフォルトの名無しさん:04/07/22 23:32
シェルの質問もここでいい?


1000,10,AB
2000,11,ABCDE
3000,12,AB

てな感じのテキストファイルを

1000,10,AB△△△
2000,11,ABCDE
3000,12,AB△△△

※△は全角スペースのつもり

でな具合に固定長になるよう空白埋めしたいんだけど、
この処理はシェルだけで実現できる?

390 :デフォルトの名無しさん:04/07/23 00:01
その機能をもったシェルを自作汁

391 :デフォルトの名無しさん:04/07/23 00:18
>>390
実は時間がなくて、シェルで組めないか時間がかかりそうであれば、
他の手段に切り替えないといけなくなってしまったのよ。
(書き方が悪かった。 スマソ)

やれば、なんとかできそうなのね。

392 :デフォルトの名無しさん:04/07/23 00:53
お前,小学生か? 息子の作文でもみてる気分になるぞ。
時間がかかりそうって何だよ,糞野郎?

393 :デフォルトの名無しさん:04/07/23 01:04
>>392
子は親の鏡ですからね。

394 :デフォルトの名無しさん:04/07/23 01:05
>>389
awk呼び出してfilterしろよ。

395 :デフォルトの名無しさん:04/07/23 01:16
>>394
うむ。できるね。
何かすぐCで考えちゃう自分に反省。

396 :デフォルトの名無しさん:04/07/23 05:36
age

397 :デフォルトの名無しさん:04/07/23 10:24
外部コマンドを使わずshellだけだとけっこう大変だね。
特にtestもexprもないようなshellだとかなりつらそうだ。
パズルとしては楽しめるかもしれない。

外部コマンドありならawkでもperlでも呼びゃ一発なので
つまらん。perlを呼ぶだけのスクリプトをshellスクリプト
と呼んでいいかというギモンはあるけどな。

ということでshellだけで書いたソース希望。


398 :デフォルトの名無しさん:04/07/23 11:54
シェルって何の事意味してるの?
bash?csh?

399 :デフォルトの名無しさん:04/07/23 12:01
シェルスクリプトというと /bin/sh に決まってるだろ


400 :デフォルトの名無しさん:04/07/23 12:02
>>386
同一セグメント内の全アドレスへ対して、
snmp情報情報を取得して判断する、
TCPなら、9100番へconnectしてRSTが帰ってこないか、
UDPならICMPのエラー返答
などで判断するしかないんじゃない?

API一発はむり。

401 :デフォルトの名無しさん:04/07/23 12:35
>>398
シェルって言ったらExplorerに決まってるだろ

402 :デフォルトの名無しさん:04/07/24 00:50
>>386
UNIXでsamba動かして、printer serverやれば?

403 :デフォルトの名無しさん:04/07/24 11:10
>>401
アホか。プログラムマネージャだ。

404 :デフォルトの名無しさん:04/07/24 12:53
>>403
ばーか、DOSSHELL しかないだろ。

405 :デフォルトの名無しさん:04/07/24 13:12
(-_-;)

406 :デフォルトの名無しさん:04/07/24 13:45
#!/winnt/system32/explorer.exe


407 :デフォルトの名無しさん:04/07/24 13:58
winntとは限らないだろ。馬鹿?

408 :デフォルトの名無しさん:04/07/24 14:02
#!/dev/null

409 :デフォルトの名無しさん:04/07/24 14:04
>>408
おまえんちの/dev/nullには+xが付いてる訳だな。

410 :デフォルトの名無しさん:04/07/24 14:06
409=407

411 :デフォルトの名無しさん:04/07/24 14:07
>>410
残念ながらハズレです;

412 :デフォルトの名無しさん:04/07/24 14:09
>>407
環境に応じて各自書き換えるくらい常識だろ。

413 :デフォルトの名無しさん:04/07/24 14:10
>>412
%WINDIR%

まぁ、両刀使いからしたら常識な訳だが。

414 :デフォルトの名無しさん:04/07/24 14:19
 はじめてUNIXのプロジェクトやってて、TeraTerm使って
Winから接続してコンパイルしてんですけど、UNIXって
VC++みたいにステップ実行できる環境ってないんですか?



415 :デフォルトの名無しさん:04/07/24 14:19
>>414
gdb。

emacsがあればモアベター


416 :デフォルトの名無しさん:04/07/24 14:47
>>414
WindowsのcygwinのXFree86入れてdddとか。

417 :デフォルトの名無しさん:04/07/25 11:26
UDPのソケット使っててselect待ちしてるんですけど、特定のFDが有効かどうかって判断できないでしょうか?
タイムアウト設定してポーリングっていうのは負荷がかかりそうなのであまりやりたくないです。

418 :デフォルトの名無しさん:04/07/25 12:39
「有効」ってどういう状態?

419 :デフォルトの名無しさん:04/07/25 14:44
夏だな。

420 :デフォルトの名無しさん:04/07/25 14:49
VC++もgdbもステップ実行に見せかけてるだけ。
インタプリンタじゃあるまいし。

421 :デフォルトの名無しさん:04/07/25 15:06
夏だな。

422 :デフォルトの名無しさん:04/07/25 15:20
これが夏厨認定厨?

423 :デフォルトの名無しさん:04/07/25 16:30
>>417
タイムアウト時間無しのselectに書けるというのはどうか?

424 :デフォルトの名無しさん:04/07/25 16:31
>>422
取りあえず>>421みたいになんでも夏と言えば解決すると思ってる方がにわかに急増するのも夏ならではですね。

425 :デフォルトの名無しさん:04/07/25 17:57
>>414
どこかで聞いたような… 

ステップ実行できない環境でも、不便に思ったことはないな。 作り方にもよるんだろうけど。

426 :デフォルトの名無しさん:04/07/25 18:08
414とお前がデバッガを使いこなせていないことは関係ない

427 :デフォルトの名無しさん:04/07/25 18:15
そこで、TRONですよ。

428 :425:04/07/25 18:25
>>426
使いこなせていない… そうだな。 ここで愚痴ることではなかった。 すまんね。

429 :デフォルトの名無しさん:04/07/26 01:18
sleep()
ってそんなに負荷かかるんですか?

430 :デフォルトの名無しさん:04/07/26 01:22
>>429
実測なさい。

431 :デフォルトの名無しさん:04/07/26 01:23
>>430
手法は?

432 :デフォルトの名無しさん:04/07/26 01:29
>>431
好きになさい。

433 :デフォルトの名無しさん:04/07/26 08:26
眠るのになんで負荷がかかるのよ

434 :デフォルトの名無しさん:04/07/26 08:28
for(;;) sleep(0)したらヘビーループになるな

435 :デフォルトの名無しさん:04/07/26 09:06
>>434
for(;;);

for(;;)sleep(0);
とはかなり意味が違う


436 :デフォルトの名無しさん:04/07/26 12:14
むしろ、sleep(0)を書く方が分裂症。

437 :デフォルトの名無しさん:04/07/26 12:21
実装によるかも知れんが取りあえずソース読んでからものを言えと。>>436

438 :デフォルトの名無しさん:04/07/26 12:28
ソース公開されたOSばかりじゃない

439 :デフォルトの名無しさん:04/07/26 12:30
>>438
じゃあベンチ取れば?

440 :デフォルトの名無しさん:04/07/26 12:31
夏だな

441 :デフォルトの名無しさん:04/07/26 12:37
>>440
で、解決しようとする奴が大量に沸くのも夏ならではでし。

442 :436:04/07/26 13:04
>>437
何が言いたいのかはわかる。そしてそれは実装に依存しないか?
それに、1アプリがそこまで見込んで、やるべき処理なのかが疑問。

443 :デフォルトの名無しさん:04/07/26 13:07
>>442
少なくともOSに制御は帰る・・・のか?

444 :デフォルトの名無しさん:04/07/26 13:10
>>443
OS?カーネルの事だね。

445 :デフォルトの名無しさん:04/07/26 13:42
>>437
そこまでするとなると、もはや制御系のコーディングだ。

446 :デフォルトの名無しさん:04/07/26 17:35
>>445
制御系であんな高級なスケジューラを使わせてもらえる事なんて希です。

447 :デフォルトの名無しさん:04/07/26 17:35
>>445
リアルタイムOSって制御系的な分類で良いんでしょうか?

448 :デフォルトの名無しさん:04/07/26 17:41
どうしてそんなに分類したがるのだろう

449 :句読点書けないバカをサマージャンボする俺:04/07/26 17:43
>>448


450 :デフォルトの名無しさん:04/07/26 17:45
>>447
制御系ではリアルタイム性が必要なことが多いつーだけでしょ。

ちなみにリアルタイム性というのは、
ある事象に対して一定時間内に反応できることが保証される
みたいなこと。

451 :デフォルトの名無しさん:04/07/26 17:46
ゲーム系

452 :デフォルトの名無しさん:04/07/26 17:50
>>450
ハードリアルタイムはそう言う位置づけですね。

453 :デフォルトの名無しさん:04/07/26 18:06
ソフトリアルタイムは似非リアルタイム

454 :デフォルトの名無しさん:04/07/26 23:40
ソフトリアルタイム=クロックカウント派
似非リアルタイム=まあこんなもんやろ派

455 :デフォルトの名無しさん:04/07/27 00:18
クロック数を数えたりして実行速度を上げることはリアルタイム性とは関係ない。
450が言うように、一定時間内に反応できることが「保証される」ということが重要。
一定時間がどれくらいかというのは用途によって異なる。

456 :デフォルトの名無しさん:04/07/27 00:20
>>455


457 :デフォルトの名無しさん:04/07/27 00:37
>>455
ものすごく多いプロセスを生成、実行しても保証されるわけ?
そういうことが可能なんですか?

458 :デフォルトの名無しさん:04/07/27 00:39
>>457
実行形の資源が有限である以上そんなこと不可能なの常識で分かるでしょう。

459 :デフォルトの名無しさん:04/07/27 00:40
それを一定の精度で保証するスケジューラを持ってるOSを
リアルタイムOSってゆーんじゃ?

460 :デフォルトの名無しさん:04/07/27 00:48
>>458
では、そのリアルタイムOSのスペックには
最大同時生成プロセス数〜個とか書かれているのでしょうか?

461 :デフォルトの名無しさん:04/07/27 00:55
動いてるプロセスすべてがリアルタイムなスケジューリングを必要とするわけじゃないでしょ。

462 :デフォルトの名無しさん:04/07/27 00:56
>>461
そう言う場合もあるかも知れん。

463 :460:04/07/27 01:05
>>461
いや、リアルタイムなOSみたこと無いんよ。
だからちょっと疑問に思ったわけですよ。

でも本当のところ内部はどうなってるんでしょうか?

464 :デフォルトの名無しさん:04/07/27 01:09
明確な定義があるかどうかは知らないが
http://www.linux.or.jp/JF/JFdocs/RTLinux-HOWTO.html

465 :デフォルトの名無しさん:04/07/27 01:19
リアルタイム+スケジューラでググっと。

466 :460:04/07/27 01:21
>>464
ほう、なるほど。
ざっと見てみたが、うーむ、どうやって保証してるのでしょうか?
それとも、リアルタイムOSを使用する方は、
ある機器上でリアルタイムOSを動かし、計測しながら、
アプリを設計、作成していく物なんでしょうか?よくわからんが。

467 :デフォルトの名無しさん:04/07/27 01:23
>>466
最終的にはそらそうでしょう。ユーザアプリの応答性なんぞ保証できん。

468 :460:04/07/27 01:26
>>467
なるほどです。

469 :デフォルトの名無しさん:04/07/27 11:46
全部保証するわけじゃないわな。
特定のカーネルスレッドだけ保証したりする訳よ。
後はそのオコボレのCPU使うわけ。

470 :デフォルトの名無しさん:04/07/27 12:31
>>466
ユーザプロセスに対するリアルタイム性の「保証」って言うのは、例えば
・少なくとも 18msec 毎にプロセスにCPUが割り当てられる
・CPUが割り当てられた場合には、少なくとも5msecはCPU時間を消費することができる
という風にスケジューリングが厳密に行われる、ということです。

んで開発者はそれらの情報+ハードウェアのスペックに基づいて、
時間内に実行可能なアルゴリズムを選択してプログラムを書く。
ビデオ再生なら「720x480x30fpsはOKだ。でもAAC音声のデコードは無理なのでAC3にしよう」とか。


471 :デフォルトの名無しさん:04/07/27 13:27
なんか全然ありがたくないな

472 :デフォルトの名無しさん:04/07/27 13:28
どういうのがありがたいんだろう。。

473 :デフォルトの名無しさん:04/07/27 13:40
>>471
馬鹿晒して嬉しいですか?

474 :460:04/07/27 13:46
>>470
詳しい説明、ありがとうございます。
相当わかってきました。

475 :デフォルトの名無しさん:04/07/29 23:18
ハードリアルタイムというのは存在しえないと、
申しているところあるようですが。
そうするとハードリアルタイムといってる達は、
誇大宣伝をうたってるという事ですか?

476 :デフォルトの名無しさん:04/07/30 03:17
極論するとリアルタイム処理なんて存在しないことになる。
極論馬鹿はどこにでもいるからこればかりはどうしようもない。

477 :デフォルトの名無しさん:04/07/30 09:21
>>475
誰がもうしているって?

478 :デフォルトの名無しさん:04/07/31 20:09
システム依存の定数で

_SOMECOSTANT

__SOMECONSTANT

_SOMECONSTANT_

__SOMECONSTANT__

とか色々と異なるスタイルのものがありますが、
これらに何か意味があるのでしょうか?

479 :デフォルトの名無しさん:04/07/31 20:19
>>478
なるべく他とかぶらないように♪

480 :478:04/07/31 20:26
>>479
ということは、_がたくさん付いている変数ほど、新しく定義された変数ということでしょうか?
_がたくさん付いている変数ほど実際にプログラムから参照される頻度が高いということですか?

481 :478:04/07/31 20:27
いや、違いますね。なんか妄想が先走ってヘンなことを書き込んでしまいますた。
もう来ません。

482 :デフォルトの名無しさん:04/07/31 23:43
>>478
お前は頭に_, __をつけるな。
言いたいことはそれだけだ。

483 :477:04/08/02 17:19
なんかスルーされている。気になってしょうがないんだけど。

484 :デフォルトの名無しさん:04/08/02 18:12
>>483
googleは、あなたのお友達。

485 :483:04/08/02 19:49
>>484
ああなんだ、ここの住人が申しているということじゃないのか。

486 :デフォルトの名無しさん:04/08/04 14:25
シェルとシェルスクリプトについて
体系的に説明しているサイトおしえてクレクレーヌ

487 :デフォルトの名無しさん:04/08/04 14:32
man bash

488 :486:04/08/04 15:57
>>487
まだそのレベルまで逝ってないYO!

489 :デフォルトの名無しさん:04/08/04 16:03
好きなの選べ
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=bash+%E5%85%A5%E9%96%80

490 :486:04/08/04 16:39
やだやだー
テキストのみがいいの〜
じゃないと嫌なの〜

491 :デフォルトの名無しさん:04/08/04 17:30
>>486
http://www-6.ibm.com/jp/developerworks/linux/000714/j_bash.html
http://www-6.ibm.com/jp/developerworks/linux/000714/j_bash2.html
http://www-6.ibm.com/jp/developerworks/linux/000714/j_bash3.html


492 :486:04/08/04 17:40
>>491
サンクスコ

493 :486:04/08/04 17:40
でもほんとはトップが目次形式になってるほうがいいのぉ〜

494 :デフォルトの名無しさん:04/08/04 18:22
それくらい自分で作れ。

495 :486:04/08/04 19:21
>>494
そんなこと言わないでおしえてYO!

496 :デフォルトの名無しさん:04/08/04 22:05
>>495
頑張れや。


497 :デフォルトの名無しさん:04/08/04 23:24
>>486
http://lagendra.s.kanazawa-u.ac.jp/ogurisu/manuals/sh-text/index.html

498 :デフォルトの名無しさん:04/08/05 00:47
わがままだな(w

499 :デフォルトの名無しさん:04/08/06 16:18
redhat7.3+g++3.4.0でプログラムを書いているのですが
こいつをdaemonプロセスにしないといけないんです。
forkを使えば処理は行えるのですが
終了処理を外部コマンドから
入力して正常終了するようにしたいです。
killコマンドとかじゃなく・・・ 
どのようにすればいいのですか?
ぐぐってもぜんぜん情報にありつけず困ってます。
よろしくおねがいします。


500 :デフォルトの名無しさん:04/08/06 16:40
SIGTERMのハンドラ置き換えて,PIDファイル作る。
外部コマンドは kill -TERM `cat pidfile` のシェルスクリプトで十分。

501 :デフォルトの名無しさん:04/08/06 17:54
>>499
共有メモリを使用するのはだめですか。


502 :デフォルトの名無しさん:04/08/06 18:32
>>501
むやみに複雑にするメリットはないだろ?
それにdaemonプロセスを終了させるのは1番普通のやりかた。

503 :デフォルトの名無しさん:04/08/06 18:34
まちがった。
それにシグナルでdaemonプロセスを終了させるのは1番普通のやりかた。


504 :デフォルトの名無しさん:04/08/06 18:52
>>503
クラスとかがりがり使ってるんですが
それだとデストラクタとかも普通に動いてくれるのですか?
シグナル検地するとグローバルの関数への指定しかできないため
うまく終了処理にいけないとおもうのですが・・・
クラスにstaticなメンバーつくって終了処理をっていうことが
できればいいんですが・・・

505 :デフォルトの名無しさん:04/08/06 19:00
>>504
普通はシグナルハンドラでは、
(フラグを立てるなりして)メインのアプリケーションロジックに
対して終了依頼があったことを通知するだけ。

そっから先は喪前様のプログラムがちゃんと外部からのイベントを
契機として終了可能にできているかどうか次第。

506 :デフォルトの名無しさん:04/08/06 19:05
そもそも、シグナルを受け取ることと異常終了することは別ですよ...。

507 :デフォルトの名無しさん:04/08/06 19:15
>>506
意味がわかりにくひ・・・きっと「異常」ってのは編集ミスで残ったに違いない!

508 :デフォルトの名無しさん:04/08/06 19:30
シグナル受けとったら否応無しにアボートさせられると思ってるのかとおもたのです。
killコマンドじゃなくとか、デストラクタがとかゆってはるから。

509 :デフォルトの名無しさん:04/08/06 19:36
なるほど。漏れは、
・シグナルで終了依頼を受けること
・きちんと終了すること
この2つは別のことだよ、って言ってたのかと思った。

510 :デフォルトの名無しさん:04/08/06 20:53
FIFO でもつかっとけ。

511 :デフォルトの名無しさん:04/08/07 07:49
シグナルハンドラが走った時点でlongjumpが入るから、ローカル変数のデストラクタなんて走る機会がないと思った。



512 :デフォルトの名無しさん:04/08/07 07:54
え”?

513 :デフォルトの名無しさん:04/08/07 09:32
わけわかめ

514 :デフォルトの名無しさん:04/08/07 10:34
やっぱりWincowsの方が20年新しいだけあって、
色んな概念が分り易いよな。

515 :デフォルトの名無しさん:04/08/07 10:42
>>514
牛たちに勝利せよ!21世紀らしい斬新なOS名だな。

516 :デフォルトの名無しさん:04/08/07 10:45
勝ち組の雌牛って感じかな

517 :デフォルトの名無しさん:04/08/07 11:25
>>511
> シグナルハンドラが走った時点でlongjumpが入るから、

そりゃお前のプログラムの問題だろ。


518 :デフォルトの名無しさん:04/08/07 11:27
>>517
よくわかってないですがメッセージキューみたいにシグナルハンドラの実行を任意の時点まで遅延できるんですか?


519 :デフォルトの名無しさん:04/08/07 11:39
>>518
sigsetmaskとか

シグナルハンドラにごちゃごちゃ書くのは感心しないが。


520 :デフォルトの名無しさん:04/08/07 11:46
ハンドラはキューにメッセージ乗せるだけ、という使い方が安全かなあ
あ、キューの排他が要るね・・・


521 :デフォルトの名無しさん:04/08/07 11:53
>>520
メイン処理でキューの排他中にシグナルハンドラが走ったら困りませんか?
待ってても処理はシグナルハンドラに移ってるからいつまでも解放されることがないわけで。

キューへの処理がアトミックなら問題ないんですけどね。



522 :デフォルトの名無しさん:04/08/07 12:30
>>521
NIX関係ないプログラミング初級の話なんだが、

メイン処理のキューの排他を、
signalのブロックで囲めばいい。

メンスレッドがI/O扱う類いのものなら、
>>510も検討せよ。

523 :デフォルトの名無しさん:04/08/07 14:20
age

524 :デフォルトの名無しさん:04/08/07 15:42
排他が必要ってことは、シグナルハンドラは別スレッド(?)で動いてる
ようなものってことですか?

マンドクセ。

525 :デフォルトの名無しさん:04/08/07 15:49
別スレッドっていうか、シグナルは割り込みだよ。

526 :デフォルトの名無しさん:04/08/07 16:27
signalは標準C関数

527 :デフォルトの名無しさん:04/08/07 16:40
標準?

528 :デフォルトの名無しさん:04/08/07 17:13
ANSI Cの規格にありますよ。

529 :デフォルトの名無しさん:04/08/08 19:57
シグナルがよくわかってない>>499が作っているものは
実行環境がLinuxでC++でマルチスレッドを使っているんだ。
その上シグナルを入れたら、不思議な踊りを踊り出すぞ。

>>499はリチャードの本を一度読んでからやった方がいいってこった。


530 :デフォルトの名無しさん:04/08/08 20:42
killっていう名前は明らかに命名ミスだよな。
汎用シグナル送信コマンドなのに、killなんていう過激な単語を割り当ててしまったせいで
>>499のような初心者がこのコマンドを悪魔のように感じてしまう。
責任者でてこーい!

531 :デフォルトの名無しさん:04/08/08 21:14
UNIXバッドノウハウコンテストの人気投票で何位ぐらいかな<kill

532 :デフォルトの名無しさん:04/08/08 21:40
>>530
大昔はプロセスを止めることしか出来なかったので、
理にかなった命名なのです。
creat(2)と同じで、伝統のある名前なのです。

しかし…いくら互換性といっても物には限度があるよなあ。


533 :デフォルトの名無しさん:04/08/08 21:49
UNIX関係者にに命名センスを求めるのが間違い

534 :デフォルトの名無しさん:04/08/08 23:13
man co
とかやってヨダレたらしてるおまいらが言うなよwww

535 :デフォルトの名無しさん:04/08/08 23:18
>>530
悪魔のように感じるぐらいで丁度いいんだよ。
それが汎用シグナル送信コマンドであることを理解しないうちは、「デーモン」なんか書いてはいけないということだ。

536 :デフォルトの名無しさん:04/08/08 23:38
>>534
daemon=悪魔とか言ってる奴も然り。

537 :デフォルトの名無しさん:04/08/09 00:00
daemon load

538 :デフォルトの名無しさん:04/08/09 06:02
ドラえもん

539 :デフォルトの名無しさん:04/08/09 11:21
>>533
というか、シンボルなんて他と違うことだけに意味を持つっていう
原則に拘るべきだな。UNIXみたいな30年も互換性を維持してきた
システムならなおさら。物事を抽象的に眺められる視点が得られるなら
ものの名前なんてどうでもいいと思うね。もちろん分り易い名前が
ついてるに越したことはないけど、そこばかりに目が逝ってしまう
ようじゃダメだろう。

540 :デフォルトの名無しさん:04/08/09 11:35
kill -KILL /bin/kill

541 :デフォルトの名無しさん:04/08/09 17:28
>>539
どこを縦読み?

542 :デフォルトの名無しさん:04/08/09 18:04
>>541
おれなんかおかしなこと言ったか?

543 :デフォルトの名無しさん:04/08/09 18:39
物事を抽象的に眺められる視点が得られるなら
ものの名前なんてどうでもいいと思うね。

544 :デフォルトの名無しさん:04/08/09 18:44
ああ、そっちの人ですか。まあ好きに何でも反論してください。

545 :デフォルトの名無しさん:04/08/09 21:42
アプリとシステムは名前で結ばれてるわけじゃないんで、さっさと変えればいいのに。

546 :デフォルトの名無しさん:04/08/09 21:48
>>545
そのうちシステムとユーザーひっくるめてWindowsにリプレースされます。

547 :デフォルトの名無しさん:04/08/09 22:19
で、プログラマは取り残されると 〆(。。)


548 :デフォルトの名無しさん:04/08/09 22:24
>>543
物事を抽象的に表現するには適切な名前付けが不可欠だと思われ。

お前の各プログラムの基底クラスにmankoとか付けるのいい加減やめてくれ。



549 :デフォルトの名無しさん:04/08/09 23:03
>>548
>>539に言えよ。

550 :デフォルトの名無しさん:04/08/09 23:06
manko

551 :名案!:04/08/09 23:14
KillEx()

552 :マリー:04/08/09 23:29
シグナル受信専用スレッドを用意して、そこから終了イベントをうければいいじゃない

553 :デフォルトの名無しさん:04/08/11 05:37
age

554 :デフォルトの名無しさん:04/08/11 12:50
>>552
そんな窓みたいな手法はいや。
でも、WaitForMultipleObjectsみたいなのがときどき欲しくなるなあ。


555 :デフォルトの名無しさん:04/08/11 14:57
え、シグナル受けるスレッド1個だけに限定するのは普通でしょ?

556 :デフォルトの名無しさん:04/08/11 15:07
>>555

557 :デフォルトの名無しさん:04/08/13 05:04
>>555
禿しく同意。
ttp://docs.hp.com/ja/B2355-60104-05/sigwait.2.html
> マルチスレッドプロセスでのシグナル処理法として推奨する方法は、すべての
> スレッドで重要なシグナルをブロックさせ、1つのスレッドをsigwait関数呼び
> 出し専用にして、シグナルを待たせることです。

558 :デフォルトの名無しさん:04/08/13 07:37
>>557
ん?今からwebサイトでっち上げて好き勝手な論理を正当化しても良いんだが。


559 :デフォルトの名無しさん:04/08/13 12:27
Bシェルのコーディング規約が乗っているHPなんか、ないでしょうか?

560 :デフォルトの名無しさん:04/08/13 12:43
スタイルを統一しないと破綻するような巨大なスクリプトなんて書くなよ
スクリプトのコーディングなんてテキトーでいいんだよ

561 :559:04/08/13 13:00
>>560
そうですよね、普通規約なんか設けませんよね。
ありがとうございます。
バッチの質問スレで聞いて、それでも同じような回答ならあきらめます。


562 :デフォルトの名無しさん:04/08/13 13:02
MSにはBATファイルのコーディング規約がある

563 :デフォルトの名無しさん:04/08/13 13:41
AT&TのUSGには規約あったんじゃないかな?
奴等大量のscriptを書いてたからな。

564 :デフォルトの名無しさん:04/08/13 13:46
linuxのってないの?

そこからbashismを除けばいい感じでは?


565 :デフォルトの名無しさん:04/08/13 13:49
linuxのってないの?

そこからbashismを除けばいい感じでは?


566 :デフォルトの名無しさん:04/08/13 19:17
なんで二回書くの?

なんで二回書くの?

567 :デフォルトの名無しさん:04/08/14 00:00
>>558
一個人の戯言よりはHPの中の人の言ってることのほうが
いかにも信用できそうだろ

568 :デフォルトの名無しさん:04/08/16 06:26
age

569 :デフォルトの名無しさん:04/08/16 17:40
/usr/bin/htpasswd / test
上記のコマンドを実行したときに、自動的に決まっているパスワード(test123等)も入力されるスクリプトって作れますか?


570 :デフォルトの名無しさん:04/08/16 17:42
スレ違わなくない?

571 :デフォルトの名無しさん:04/08/16 17:44
板違い

572 :デフォルトの名無しさん:04/08/16 17:47
なんだってー!?

573 :デフォルトの名無しさん:04/08/16 21:38
>>569
passwd << EOF
omaemona
omaemona
EOF

で何とかならないっすか?もっと高度なことをしたかったらexpectだっけ?

574 :デフォルトの名無しさん:04/08/19 17:10
禿しくガイシュツな質問だと思いますけど、
unix環境で最も簡単にグラフィックを表示するにはどうすればよろしいのでしょうか?
グラフィック領域の任意の場所に(小さな)bmp画像などを表示する方法が分かりません。
よろしくお願いします。

575 :デフォルトの名無しさん:04/08/19 17:50
グラフィック領域って何?
独立したプログラムでいいの?
それともプログラムの一部にするの? それはどんなプログラム?


576 :デフォルトの名無しさん:04/08/19 18:18
>>575
ウィンドウの中に適当に設定したグラフィック領域です。
プログラムの一部として使いたいのです。
ゲームプログラムで、特定のキャラクターを表示させたりしたいのですが、
グラフィック部分が禿しく難しくて挫折しています。
アルゴリズム部分はどうにでもなるのですが、表示だけが出来ません。
出来れば表示よりもアルゴリズム本体に手間をかけたいので、
最も簡単にグラフィックを表示する方法が知りたいのです。
よろしくお願いしますm(_ _)m

577 :デフォルトの名無しさん:04/08/19 18:22
>>576
最も簡単ではないかもしれないけど、そこそこ簡単で、たぶん >>574 の使ってる
プラットフォームにも存在して、かつ知っておいて将来役に立つかもしれないものとして
OpenGL を勧める。

「最も」簡単なものは世界中の全てのライブラリを知っている誰かが教えてくれるだろう。

578 :デフォルトの名無しさん:04/08/19 18:23
もうちょっと開発環境詳しく書いたら。
LinuxでGNOMEでC++でゲーム作りたいとか。

ポータブルにハイパフォーマンスに描きたいならOpenGLじゃないの。

579 :デフォルトの名無しさん:04/08/19 18:52
一応Javaという選択肢もあるが。
bmpはいまいち簡単じゃないけど。

580 :デフォルトの名無しさん:04/08/19 19:12
>>577
OpenGLなら使えますが、bmpなどを表示するのが激しく難しそうです。
Window全体ではなくて、任意の場所となると。

>>578
まさにその環境です!C++ではなくてCですけど。

>>579
Javaでぐぐってみても、今ひとつ簡単な方法がなかったみたいです。
Javaでもいいのですが、欲を言うとCで作ったプログラムと
協力するプログラムにしたいです。

581 :デフォルトの名無しさん:04/08/19 19:36
>>580
gnome 使ってるっていうことなら、gtk+ の drawable あたりのサンプル
プログラムでものぞいてみたらどうよ?

582 :デフォルトの名無しさん:04/08/19 20:06
>>580
xbubbleとかのsourceでも参考にしたら?
↑結構綺麗なコード。

bmpうんぬんはimlib使えば? libgdk-imlibとかさ。

583 :デフォルトの名無しさん:04/08/19 20:10
SDL つかって SDL_LoadBMP(), SDL_BlitSurface(), SDL_UpdateRect()

584 :デフォルトの名無しさん:04/08/19 22:18
わしもゲームならSDLがいいと思う。
bmp以外も使うならSDL_imageを使えばいいし。

585 :580:04/08/19 23:23
>>581
そうしてみます。
・・・やっぱり、グラフィックを使おうとすると、ある程度手間はかかるんですね・・・。

>>582
xbubbleが入っていたら使ってみます(自分でインストールする権限がないので)。

>>583
SDLは入ってなかったみたいです・・・。

>>584
SDLって(ぐぐったら)結構便利そうでした。
でも使えない○| ̄|_

586 :デフォルトの名無しさん:04/08/19 23:31
「権限が無い」って、 root の権限が無いんじゃなくて、
「勝手に他所のソフトをコンパイルしちゃいけません」ってこと?

SDL なら ./configure --prefix=$HOME/local とかすれば
自分の権限で入れられるはずだけど。

587 :デフォルトの名無しさん:04/08/20 00:05
>>586
makeとかinstallを使う権限がないのでは。

588 :デフォルトの名無しさん:04/08/20 00:13
>>586
>「権限が無い」って、 root の権限が無いんじゃなくて、
>「勝手に他所のソフトをコンパイルしちゃいけません」ってこと?
ルートの権限です。

>SDL なら ./configure --prefix=$HOME/local とかすれば
>自分の権限で入れられるはずだけど。
展開したときのサイズは大きくないですか?
100メガもあったら少しきついてす(一人に割り当てられているハードディスク容量はそんなに大きくないので)。

589 :デフォルトの名無しさん:04/08/20 00:19
SDLだけならライブラリとヘッダで1Mbyteない。

ただ下請ライブラリがあれこれ必要。
gnome環境らしいからライブラリほとんどはあると思うけど、
ヘッダは微妙。

590 :デフォルトの名無しさん:04/08/20 00:22
ソースは展開すると 10Mbyte 程。

591 :デフォルトの名無しさん:04/08/20 00:25
考えてみると、ホームディレクトリにインストールすると、

#include <〜.h>

と書いたときにインクルードされないような気が・・・
そこは、

#include "/usr/・・・/〜.h"

とか書き直すしかないんでしょうか?

592 :デフォルトの名無しさん:04/08/20 00:26
>>591
gccなら-Iオプションでも使えばいい。

593 :デフォルトの名無しさん:04/08/20 00:34
-Lも忘れるな。

594 :デフォルトの名無しさん:04/08/20 00:34
ふつうはインストール時に入る sdl-config を使う。

CFLAGS = -Wall -g -O2 `$HOME/local/bin/sdl-config --cflags`
LDLIBS = `$HOME/local/bin/sdl-config --libs`

595 :デフォルトの名無しさん:04/08/20 00:44
ふつうはLIBS

596 :デフォルトの名無しさん:04/08/20 05:25
共用計算機つかってる学生さんだろうか


597 :デフォルトの名無しさん:04/08/20 05:51
今どうやってウィンドウを出してるか(Xlib叩いてるのかGTKかQtかtkか)や
パフォーマンスどのくらい必要かとかにもよるんじゃなかろうか。

Kylixとかなら一行もコード書かなくてもbmpぐらい表示できそうだとか。

598 :デフォルトの名無しさん:04/08/20 23:09


599 :デフォルトの名無しさん:04/08/21 00:29
ようは、bmpデコードライブラリなんだよ。
これさえあれば、あとは何でもいけるだろ。

600 :デフォルトの名無しさん:04/08/21 02:43
bmpもろくに表示できないUNIX

601 :デフォルトの名無しさん:04/08/21 08:09
>>600
そんなのあるのか?

602 :デフォルトの名無しさん:04/08/21 08:42
Xか入ってなくて/dev/fb*もないとか

603 :デフォルトの名無しさん:04/08/21 12:33
>>599
>ようは、bmpデコードライブラリなんだよ。

鼻くそほじりながら書けよ。
デコードもへったくれもそのままビットマップが詰まってる。

604 :デフォルトの名無しさん:04/08/21 13:24
RLE圧縮されてるとか。
あんまし見た事無いけど。


605 :デフォルトの名無しさん:04/08/21 13:52
昔ランレングス圧縮されてる一色(赤)のBMPを添付された記憶が
展開したら500Mになりやがった

606 :デフォルトの名無しさん:04/08/21 22:34
コンソールモードでbmpって表示できるの?

607 :デフォルトの名無しさん:04/08/21 22:39
>>606
fb使えばできるんじゃ無いかい?

608 :デフォルトの名無しさん:04/08/21 23:24
>>606
SVGAlib
http://www.svgalib.org/

609 :デフォルトの名無しさん:04/08/22 02:04
そういえばKNOPPIXの起動中にペンギンが表示されるが、あれがそうか?

610 :デフォルトの名無しさん:04/08/22 09:55
>>609
ハァ?幻覚でも見てんじゃねぇの?

611 :デフォルトの名無しさん:04/08/22 10:12
それとは違う気がする

612 :デフォルトの名無しさん:04/08/22 10:41
>>609
あれはfb。

/usr/src/linux-*/drivers/video/logo/Kconfig
config LOGO
bool "Bootup logo"
depends on FB || SGI_NEWPORT_CONSOLE



613 :デフォルトの名無しさん:04/08/24 15:55
C++ で、指定された unix コマンドが実行できるか(存在するか)を調べたいです。
which target_cmd
のステータスを取ろうかなと思うのですが、
popen("which target_cmd > /dev/null 2>&1", "w");
だと、which 自体は当然正常に実行できるのでうまくいきません。
どうすればよいのやら?

それとも他によい方法があるでしょうか?

614 :デフォルトの名無しさん:04/08/24 16:08
>>613
なんで popen() を使うの?


615 : ◆Z0vd5w812U :04/08/24 16:18
>>613
環境変数PATHを分解してUNIXコマンドをstrcatしてfstat。


616 :デフォルトの名無しさん:04/08/24 17:24
>>613
access()ではだめなのか?

617 :デフォルトの名無しさん:04/08/24 17:56
accessだけをしらべるとディレクトリもX_OKにならないか?

流れ的にはこんな感じになるのかな?
getenv("PATH")
strtok(path, ":")
opendir
readdirで片っ端から調べる。
探しているなまえがあればstat
S_ISREGで調べて、access又はstatのパーミッションを調べる。
whichと同じにしたいなら見つかれば戻る。
見つからなければstrtok(NULL, ":")で最初から…。

618 :デフォルトの名無しさん:04/08/24 18:00
>>613
一つだけきいていい?
なんで第二引数を"w"にしてるの?"r"じゃなくて。

619 : ◆Z0vd5w812U :04/08/24 18:24
>>617
opendirしなくても、ディレクトリパスに目的のコマンドをstrcatして
fstatかaccessでファイルの存在や実行可能状態を調べればよいよ。


620 :デフォルトの名無しさん:04/08/24 22:44
>>613
system("which target_cmd > /dev/null 2>&1") で戻り値見ればいいと思うが...。

621 :デフォルトの名無しさん:04/08/25 00:42
>>620
それだと存在するかどうかはわかるけど、実行できるかどうかはわからない。

622 :デフォルトの名無しさん:04/08/25 00:57
じゃあ"bash -c 'type target_cmd'"で。

623 :デフォルトの名無しさん:04/08/25 01:48
PATHのサーチも期待してるんでしょ

624 :デフォルトの名無しさん:04/08/25 21:24
>>621
はぁ ?
which は、実効属性ぐらいは当然見てるんだが。

まさか、ファイルの中身まで見ろとか言ってるんじゃないよな。

625 :デフォルトの名無しさん:04/08/25 21:24
s/実効/実行/

626 :デフォルトの名無しさん:04/08/26 02:39
>>624

627 :デフォルトの名無しさん:04/08/27 07:00
>>624
/home/toru # touch /sbin/ahoka.txt
/home/toru # chmod 666 /sbin/ahoka.txt
/home/toru # which ahoka.txt
/sbin/ahoka.txt
/home/toru #


628 :つまり実装による:04/08/27 12:51
$ sudo mkdir /usr/local/bin/ahodaro.d
$ which ahodaro.d
$ echo $?
1
$ sudo touch /usr/local/bin/ahodaro.txt
$ which ahodaro.txt
$ echo $?
1
$ which test
/usr/bin/test
$ echo $?
0
$ sudo rm -rf /usr/local/bin/ahodaro.*

629 :デフォルトの名無しさん:04/08/28 14:16
age

630 :デフォルトの名無しさん:04/08/31 13:53
age

631 :デフォルトの名無しさん:04/09/03 03:00
悩んでるんで教えて下さい。
ファイルをopenしてfstat()で検査してエラーだった場合、
そのファイルディスクリプターをcloseすべきでしょうか?

632 :デフォルトの名無しさん:04/09/03 03:14
すべき

633 :デフォルトの名無しさん:04/09/03 03:21
やっぱりそうですよね。すっきりしました。

634 :デフォルトの名無しさん:04/09/03 03:24
ずいぶん簡単に納得するんですね

635 :デフォルトの名無しさん:04/09/03 06:30
普通だろ。自分の予想と逆のことを言われた場合はともかく。


636 :デフォルトの名無しさん:04/09/03 11:49
もしopenされてなかったらcloseしたらおかしくなっちゃうかもよ

637 :デフォルトの名無しさん:04/09/03 12:04
openがくれたfdは信用するなってこと?それは困るなあ

638 :デフォルトの名無しさん:04/09/03 15:50
>fstat()で検査してエラーだった場合

例えばどんな?

639 :デフォルトの名無しさん:04/09/03 17:16
closeにfstatの値によっては呼ばなくていい
なんて書いてないんだからcloseしろ

640 :デフォルトの名無しさん:04/09/03 17:43
もうめんどうくさいから exit でいいよ。

641 :デフォルトの名無しさん:04/09/03 20:53
ファイルディスクリプタとファイルポインタの違いってナニ?
なんで二つあるの?

642 :デフォルトの名無しさん:04/09/03 21:11
UNIXのシステムコールで使うのがファイルディスクリプタ.
ファイルポインタはCの入出力ライブラリ.


643 :デフォルトの名無しさん:04/09/03 21:19
ファイルディスクリプタに対応したFILE構造体を作成できるのに、
なんでディスクリプタなんていうものがあるの?

644 :デフォルトの名無しさん:04/09/03 21:30
>>643
残念。そうとは限らない。

645 :デフォルトの名無しさん:04/09/03 21:34
shell をつくりたいのですが何から勉強したらいいですか?

646 :デフォルトの名無しさん:04/09/03 21:39
>>644
fdに対応したFILEを作成する関数ってナニ?どんな場合に失敗するの?

647 :デフォルトの名無しさん:04/09/03 22:42
>>645
既存のshellのソースを読むとか.


648 :デフォルトの名無しさん:04/09/03 23:35
>>645
fork(2), execve(2)
wait3(2), exit(3)

を使って引数を実行するプログラムを。
$ ./a.out ls -l
で、ls -lを実行するプログラム。

open(2), close(2)
を使ってredirectを実現。

pipe(2), dup2(2)
を使ってpipeを実現。



649 :デフォルトの名無しさん:04/09/04 04:31
>>646
fdopen(3)
逆に FILE * -> file descripor なら fileno(3)

詳細はman参照。

650 :デフォルトの名無しさん:04/09/04 11:48
>>648
リダイレクトとな?

651 :デフォルトの名無しさん:04/09/04 14:52
おすすめはfopen->filenoの順

652 :デフォルトの名無しさん:04/09/04 15:18
リダイレクトをやるならdup(2)も勉強しておきたいところだ。


653 :デフォルトの名無しさん:04/09/05 22:31
>>651
filenoした後って、始末どうすんの?
fclose呼ぶの?

654 :デフォルトの名無しさん:04/09/05 22:38
普通はそうだろ。


655 :デフォルトの名無しさん:04/09/05 23:10
>>653
もちろん。

656 :デフォルトの名無しさん:04/09/08 09:59
UNIXプログラミング始める前に、スティーブンス丸暗記が基本ですか?

657 :デフォルトの名無しさん:04/09/08 21:03
暗記より、説明読みながらサンプルプログラムを走らせたり改造したりするのが基本かと。
あのヘッダを自分の環境に合わせて直すだけでも貴重な経験になるはず。

658 :デフォルトの名無しさん:04/09/08 23:10
close(1)として標準出力を一旦閉じた後、再び開き直すにはどうしたら
いいですか?
苦し紛れにstdout = fopen(ttyname(1), "w");
とかしてみたんですけど、printf()系は復活しましたがcoutは閉じたまま
でした。

659 :デフォルトの名無しさん:04/09/08 23:16
C言語で, プラグインのようなものをつくりたいのですが可能なんでしょうか?

660 :デフォルトの名無しさん:04/09/08 23:16
もちろんだ

661 :デフォルトの名無しさん:04/09/08 23:21
どうやればいいんでしょ;;

662 :デフォルトの名無しさん:04/09/08 23:24
>>661
どうって、決まりに沿って書くだけだが。

663 :659:04/09/08 23:28
>>662
その決まりがわからないのですが,
その決まりはどこを見たらわかるのか教えていただけませぬか?

664 :デフォルトの名無しさん:04/09/08 23:29
>>658
dup2

665 :デフォルトの名無しさん:04/09/08 23:32
>>663
プラグインを作りたいソフトの資料はないの?


666 :659:04/09/08 23:35
>>663
すんません. 言葉の使い方間違ってたようで.
プラグインの呼び出し側をつくりたいのです.


667 :デフォルトの名無しさん:04/09/08 23:38
>>オーメン
もう少しやりたい事をはっきりと書いて欲しいものだが
ttp://www.linux.or.jp/JM/html/LDP_man-pages/man3/dlopen.3.html
のような事?

668 :デフォルトの名無しさん:04/09/08 23:38
>>666
APIの設計

669 :デフォルトの名無しさん:04/09/08 23:48
>> 664
こんな感じですか?↓
string tty = ttyname(1);
fclose(stdout);
dup2(1, open(tty.c_str(), O_WRONLY));

駄目でした...

670 :659:04/09/08 23:49
>>667
すんません...

ソフトをリコンパイルすることなく,
入力ファイルに書いてある関数を呼び出したい.
その時, そのソフトで定義していない関数も呼び出せるようにしたい.

... で伝わりますでしょうか.


671 :デフォルトの名無しさん:04/09/08 23:50
>>669
クローズ前にdup2

672 :デフォルトの名無しさん:04/09/08 23:52
>>670
>>667のリンク先を見ていないでしょ?

673 :デフォルトの名無しさん:04/09/08 23:52
>>670
お前は細胞分裂からやりなおせ

674 :デフォルトの名無しさん:04/09/08 23:54
他のプログラムのサブルーチンを実行したいって言ってるのか?

675 :デフォルトの名無しさん:04/09/08 23:57
プラグイン作りたい奴はCOMの勉強をするとよいよ

676 :659:04/09/09 00:02
>>672
みました.

>>673
どうやったらできますか?

>>674
はい.

いくつかキーワードでてきたので自分で調べなおしてみます.
ありがとうございました.

677 :デフォルトの名無しさん:04/09/09 00:07
>>676
二度とくるなよ(^-^)/~

678 :デフォルトの名無しさん:04/09/09 00:09
プラグインなんて言うからこんな事になるんだ

679 :デフォルトの名無しさん:04/09/09 00:21
>>658
stdoutやcoutとして使っているものを、close(1)しちゃいかん!


680 :428ツ?ツ?:04/09/09 00:24
>> 671
下のようにしてみました。
int fd = dup(1);
cout << "show (before close)" << endl;
close(1);

cout << "not shown" << endl;

dup2(fd, 1);

cout << "show (cout)" << endl;
printf("show (printf)\n");

結果は
show (before close)
show (printf)

coutが復活してない模様です...

681 :デフォルトの名無しさん:04/09/09 00:27
>>680
> coutが復活してない模様です...

それは、きっと、

> cout << "not shown" << endl;

のせいだよ。コメントアウトしろ。

しかし、動いても実装依存で、close(1)しちゃいかん!

682 :679:04/09/09 00:28
ageちゃった…

それからclose(1)する前にflushくらいしろよ。

しかし、close(1)しちゃいかん!

683 :デフォルトの名無しさん:04/09/09 00:29
何故closeしたがってるんだろうな

684 :デフォルトの名無しさん:04/09/09 00:30
どうせまた開くのにな

685 :デフォルトの名無しさん:04/09/09 00:46
すみません。
cursesを使ったプログラムをX Window上のktermとかで動かしたいのですが、
端末の行カラム(ウィンドウサイズ)が動的にされたタイミングを捕まえることは
できるでしょうか? それに合わせて表示を変更できたらなぁ、と思ってます。
その方法を教えてくださいませ。お願いします。

686 :デフォルトの名無しさん:04/09/09 00:53
SIGWINCH

687 :デフォルトの名無しさん:04/09/09 00:58
>>685
なるほど、そういうシグナルが来るわけですな。
ためしてみます。サンキュー

688 :687:04/09/09 01:00
>>685でなく>>686でした

689 :デフォルトの名無しさん:04/09/09 01:10
>> 683
やりたいのはpipe(2)+fork(2)を使って
親の出力 → パイプ → 子の入力
と繋ぎ、しかる後に子が先に死ぬんで
親の出力 → 画面
と戻したいのです

dup2(パイプの片方, 1);
とやる過程で中でclose(1)されてるので、それを復活させたいと
いうのが発端です。

690 :679:04/09/09 01:16
親の使うファイルハンドルが標準出力である必然性は何なんでしょう?

691 :デフォルトの名無しさん:04/09/09 01:42
>> 690
親が叩くとあるライブラリが、デバッグログ相当のものを標準出力
に吐いています。そのライブラリは非公開です

692 :デフォルトの名無しさん:04/09/09 02:19
子が死なずに stdout に吐き出すようにすればいいのでは。

693 :デフォルトの名無しさん:04/09/09 02:46
>> 692
1.子は標準入力の捕捉と共有メモリへの書き出しのみを担当させたい
2.子はライブラリの使用箇所が終わり次第消したい
3.親のみが知りえる情報とログを加工してmainの最後に出力したい

という理由で子が吐くというのはやりたくないです

694 :デフォルトの名無しさん:04/09/09 09:24
やれ

P.S.
実装依存のコードでも良ければ、環境を書け。

695 :693:04/09/09 10:09
Vine Linux 2.6 & g++2.95.3もしくは
Cygwin 1.5.9 & g++ 3.3.1
です

696 :デフォルトの名無しさん:04/09/09 12:26
>>689
dup しとけばいいじゃん。

697 :デフォルトの名無しさん:04/09/09 15:56
cout を使わなければいいじゃん。

698 :693:04/09/09 22:37
>> 681
あ、ほんとだ!!
でもなぜ?

699 :679:04/09/09 23:30
closeされてんのにI/Oしたら、
cout.fail() => trueになるに決ってんでしょ。
cout.clear()してみなよ。

つーか実装依存のコード書くのはまだ早いかも…
もっとiostream勉強しる

700 :693:04/09/09 23:51
>> 699
仰せの通りfail()がtrue返し、clear()したら表示されるようになりました
failなんてフラグを持ってる事すら知りませんでした
勉強になりました

701 :デフォルトの名無しさん:04/09/10 02:26
X-WindowでMDI形式のアプリって組めますか?

702 :デフォルトの名無しさん:04/09/10 22:47:58
できます.

703 :デフォルトの名無しさん:04/09/11 01:00:41
>>702
じゃあなんでGIMPはMDIじゃないの?

704 :デフォルトの名無しさん:04/09/11 01:13:58
賢いwindow managerがあれば、MDIは欠点の方が大きい。

705 :デフォルトの名無しさん:04/09/11 01:20:16
舞黒ソフトですらSDIを推奨してるのにな

706 :デフォルトの名無しさん:04/09/11 01:37:18
えっ 真っ黒ソフトってSDIを推奨してんの?
知らなかった。どうでもいいけど。

707 :デフォルトの名無しさん:04/09/11 02:23:09
>>703
MDIだと使いにくいからでしょ。

708 :デフォルトの名無しさん:04/09/12 08:30:31
>>707
そうか?

709 :デフォルトの名無しさん:04/09/12 14:03:23
Windowsでは、CreateFileMapping,MapViewOfFileと
二つの関数をつかってマップするところが、
UNIXではmmap関数一回で済んでしまいます。
これはどうしてなんでしょうか?

710 :デフォルトの名無しさん:04/09/12 14:13:16
>>709
くだらん事言うな

711 :デフォルトの名無しさん:04/09/12 14:20:36
モスバーガーへ行って、ビックマックセットが
無いじゃないかと叫んでる893だな

712 :デフォルトの名無しさん:04/09/12 14:30:40


713 :デフォルトの名無しさん:04/09/12 14:43:33
複数のプロセスで同一のファイルに対するマップを作るとき、
ProcessA : CreateFileMapping("hoge") → MapViewOfFile
ProcessB : OpenFileMapping("hoge") → MapViewOfFile
とすることで(msyncを呼ばなくても)、内容が同期される。
つまり、共有メモリのように振舞う。
というか、win32では共有メモリはこの方法を使う。

いわゆるmmapだけでこれを実現することはできない。
・・・と思う(違ったら指摘してくだせえ)

同期が不要であれば、プロセスごとにCreateFileMappingを行えばよい。
これはmmapと同等となる。

714 :デフォルトの名無しさん:04/09/12 20:08:28
open

715 :デフォルトの名無しさん:04/09/12 20:28:37
>>713
> いわゆるmmapだけでこれを実現することはできない。
> ・・・と思う(違ったら指摘してくだせえ)

見事に間違ってる。MAP_SHAREDつけるだけでいい。

> 複数のプロセスで同一のファイルに対するマップを作るとき、
> ProcessA : CreateFileMapping("hoge") → MapViewOfFile
> ProcessB : OpenFileMapping("hoge") → MapViewOfFile

プロセスによって手順が違うのかいな。めんどくさ。


716 :デフォルトの名無しさん:04/09/12 20:41:17
マップという概念について勉強する気になった。おまえらありがとう。

717 :デフォルトの名無しさん:04/09/12 21:49:43
>>715
> 見事に間違ってる。MAP_SHAREDつけるだけでいい。

ダウト!
2つのプロセスで試してみ。mmapだけじゃできんから。

718 :デフォルトの名無しさん:04/09/12 21:54:16
msync

719 :デフォルトの名無しさん:04/09/12 21:59:11
つーか、意外にmmapの挙動は知られてないんだな。

> とすることで(msyncを呼ばなくても)、内容が同期される。

へえー

720 :デフォルトの名無しさん:04/09/12 22:19:04
そもそも Create/OpenFileMappng + MapViewOfFile の挙動を知らないから、
mmap だけで同じことができるかどうかわからんな。

721 :デフォルトの名無しさん:04/09/12 23:17:01
知らないなら黙っていればいいのにねぇ

722 :デフォルトの名無しさん:04/09/12 23:37:16
>>721
お前藻な。

723 :デフォルトの名無しさん:04/09/12 23:41:51
>>717
試してみたら、ちゃんとmmapだけで同期したんですけど。
OSの実装を考えたら同一メモリページを複数のプロセスにマップするだけなんだから、
同期しない理由がないと思うけど。


724 :デフォルトの名無しさん:04/09/13 00:45:15
MAP_SHAREDはmappingの共有で、
msync(2)はflushだから、MAP_PRIVATEの時しか意味ないだろ。


725 :デフォルトの名無しさん:04/09/13 00:54:18
The Design and Implementation of the 4.4BSD Operating System p.141

マルチプロセッサ環境なら CPU のキャッシュの関係で msync が必要になるかもね、ということ。

726 :デフォルトの名無しさん:04/09/13 00:55:27
うちのマニュアルにはファイルが更新されるのはmsyncを呼んだときだと書いてあるが、
その領域自体は複数のプロセスで共有すると書いてあるな。

727 :デフォルトの名無しさん:04/09/13 01:14:03
ファイルをマップしたとき、
メモリにマップされてる領域自体は共有されてるから、
プロセスが別だろうとなんだろうとその場で変更が見える。
でもそれは元ファイルには書き出されてないかもしれないから、
元ファイルの内容を更新するにはmsyncが必要。
みたいな。

728 :デフォルトの名無しさん:04/09/13 01:22:04
>>726
> うちのマニュアルには

釣りでないなら、uname -aくらい書けよ。



729 :デフォルトの名無しさん:04/09/13 01:32:59
>>727
> ファイルをマップしたとき、
> メモリにマップされてる領域自体は共有されてるから、

mmapのman pageをそのように記述しているOSがあるなら教えてほしい。

730 :デフォルトの名無しさん:04/09/13 01:33:57
>>728
Linux localhost 2.4.27 #2 Sun Aug 8 23:07:42 JST 2004 i686 unknown

MAP_SHARED このマッピングを、このオブジェクトをマップし た
他 の全てのプロセスと共有する。この領域への保存
は、ファイルへの書き込みと等価である。 た だ し
ファ イルが実際に更新されるのは、 msync(2) また
は munmap(2) が呼ばれたときである。

あとこっちにもhttp://www.linux.or.jp/JM/html/LDP_man-pages/man2/mmap.2.html

731 :デフォルトの名無しさん:04/09/13 01:36:10
誤訳っぽいな。

732 :デフォルトの名無しさん:04/09/13 01:45:19
>>730
> MAP_SHARED このマッピングを、このオブジェクトをマップした
> 他の全てのプロセスと共有する。

mappingを共有するんだから、メモリ空間も共有だわな。

> この領域への保存
> は、ファイルへの書き込みと等価である。

単一仮想記憶だからmmap(2)すれば当たり前だわな。

> ただし
> ファイルが実際に更新されるのは、 msync(2) また
> は munmap(2) が呼ばれたときである。

これはプロセス間のメモリ共有とは何の関係もないわな。
diskにflushしようがしまいが、共有メモリは共有メモリだからね。
それを理解してない。


733 :デフォルトの名無しさん:04/09/13 01:48:51
>>732
最初からそう言っているじゃない。

734 :デフォルトの名無しさん:04/09/13 02:38:10
なにかオブジェクトをつくったとき、ハンドルの概念でそのオブジェクトをあらわすものを
取得するようにプログラム書いてる方います?
そうれってなんのメリットがあるんでしょうか?

typedef {
void *ptr
int attribute1;
int attribute2;
}HANDLE

HANDLE CreateObjFoo()
{
ObjFoo *foo_prt;
foo_ptr=(Obj_Foo *)malloc(sizeof(ObjFoo));

HANDLE hnd;
hnd.ptr=foo_ptr;
hnd.attribute1=attribute1;
hnd.attribute2=attribute2;

return hnd;
}

735 :デフォルトの名無しさん:04/09/13 06:46:21
1)CPUCache
2)物理メモリ
3)DISK

msyncは1から2への更新のついでに、同期で2から3へも行うという理解でいいのかな
MAP_SHAREDしたときは、1から2への更新が重要というだけで

>>732
>単一仮想記憶だからmmap(2)すれば当たり前だわな。
単一仮想記憶ってなんでしょうか?

736 :デフォルトの名無しさん:04/09/13 06:50:54
>>734
具体的なコードを出してくれないと。そんなあやふやなのではねー。

適当な事をいうと、そういう類のことしてるのは
リファレンスカウントなりGCなりのメモリ管理が絡んでいる場合が多いと思う。
あと複数の種類のオブジェクトを同じHANDLEで扱いたい場合。



737 :デフォルトの名無しさん:04/09/13 07:50:00
>>735
> 1)CPUCache
> 2)物理メモリ
> 3)DISK
>
> msyncは1から2への更新のついでに、同期で2から3へも行うという理解でいいのかな
> MAP_SHAREDしたときは、1から2への更新が重要というだけで

少なくともSMPやccNUMAじゃ1と2の間の一貫性もアーキテクチャで保証されるん
だけどね。そうじゃないNUMAでOSの側でも手を打たないUNIXってどれですかね。
第一それが問題になるなら話はmmapに限らないし。

2から3もOSがいきなり落ちたりしない限り、ユーザから見れば即時にディスク
に書き込まれるのと変わらない。
書き出しはOSがページングと同じ枠組みで自動的にやってくれる。
>>730のマニュアルの訳者はそれを理解してないね。原文はもっとましな書き方
がしてある。


738 :デフォルトの名無しさん:04/09/13 07:56:50
>第一それが問題になるなら話はmmapに限らないし。

よく考えてみればそうですね。
異なるCPUで動いてるスレッドのデータ領域の話だってそうか。

全然関係ない話になるけど、
>SMPやccNUMAじゃ1と2の間の一貫性もアーキテクチャで保証される
保証されてないアーキテクチャってあるんでしょうか。ソフト側で
Cacheのフラッシュを実行しないといけないようなCPU。

739 :デフォルトの名無しさん:04/09/13 08:05:16
>>725のような書き込みを見て、OS側でCPUCache->メモリ間の転送を
制御しなくてはならないようなアーキテクチャがあるのかと思ったまでです。

むかしなんかで読んだMachのメモリマネージャの記事で、個々のCPUごとに、
専用のメモリとアドレス空間を持っているハードに対応するような話を読みました。
現在のNUMAのように単一のアドレス空間の共有を前提とするのが当たり前の
時代からみると、かなりキモイ設計のようにも見えますが。CPU間の
データ転送には特別な命令を用いる感じなんでしょうか。よく分りませんが。

VMにその頃の名残があって、>>725の記述がそれを繁栄したものだというのなら理解できます。

740 :デフォルトの名無しさん:04/09/13 08:46:13
>CPU間のデータ転送には特別な命令を用いる感じなんでしょうか。
CPUが別のCPUに割り込めるものもあるらしい。
あるいは、問題が起こりうるデータには
初めからキャッシュを使わないという解決法もある。

UNIXカーネル内部解析という本がくわしい。
http://www.amazon.co.jp/exec/obidos/ASIN/4890529306
カーネルの解説本と見せかけて、一冊まるごとキャッシュに関する解説をしている。

741 :デフォルトの名無しさん:04/09/13 09:02:59
>>723
コード晒してみ。

742 :デフォルトの名無しさん:04/09/13 09:03:10
>>740
その本、なんだか良さそうな感じですね。
今度注文してみます。

743 :デフォルトの名無しさん:04/09/13 09:08:02
>>741
むしろ同期しない方のコードを晒してもらいたい。


744 :デフォルトの名無しさん:04/09/13 10:23:06
>>734
それUNIX固有の話じゃないんじゃないの?

FILEに付いて考えてみれ

745 :デフォルトの名無しさん:04/09/13 10:38:55
このプログラムのどこが間違っているんでしょうか。Bus Errorが発生します。

#include<sys/types.h>
#include<stdio.h>
#include<sys/mman.h>
#include<unistd.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<wait.h>

int main()
{
int fd, pid;
void * p_map;
fd = open("/tmp/mmap.txt",O_RDWR|O_CREAT|O_SYNC);
pid = fork();
if(pid==0){ /*child*/
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
printf("child p_map == %d\n",(int)p_map);
//memcpy(p_map,"aaaa",4);
*(int *)p_map=4;
}
else if (pid>0){ /*parent*/
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
printf("parent p_map == %d\n",(int)p_map);
wait(NULL);
printf("mmap %d\n",*(int *)p_map);
}
close(fd);
}

746 :デフォルトの名無しさん:04/09/13 10:41:07
どこで発生したか、backtraceくらい出せよな。
どうせこういうことだろうという見当はつくが。



747 :デフォルトの名無しさん:04/09/13 10:48:53
mmap が失敗しても処理を続けようとしているところ。

748 :デフォルトの名無しさん:04/09/13 10:53:14
fork後の実行順序を決めてかかってるところもね。


749 :デフォルトの名無しさん:04/09/13 10:59:20
そりはwaitしてんだから問題なかんべ。
むしろ終了直前にわざわざcloseしていることのほうが。

750 :デフォルトの名無しさん:04/09/13 10:59:43
/tmp/mmap.txtが空だから。

751 :デフォルトの名無しさん:04/09/13 11:05:29
>>749
親プロセスの最初のprintfが子プロセスでの書き込みより先に実行されることを
仮定しちゃってると思うんだが、どうよ。


752 :デフォルトの名無しさん:04/09/13 11:51:07
少し書き換えました。>>750さんのいう通り空のファイルでは駄目なようです。
mmapではファイルサイズ分しか読み書きできないようです。それとも何か
勘違いしてるのかもしれませんが。あと/tmp/mmap.txtのアクセスモード指定が抜けてました。

#include<sys/types.h>
#include<stdio.h>
#include<sys/mman.h>
#include<unistd.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<wait.h>
int main()
{
int fd, pid;
void * p_map;
fd = open("/tmp/mmap.txt",O_RDWR|O_CREAT|O_SYNC, S_IRWXU);
write(fd,"aaaaaa",6);
//lseek(fd,6,SEEK_SET);
pid = fork();
if(pid==0){ /*child*/
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
printf("child p_map == 0x%X\n",(int)p_map);
*(int *)p_map=4;
}
else if (pid>0){ /*parent*/
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
printf("parent p_map == 0x%X\n",(int)p_map);
wait(NULL);
printf("mmap %X\n",*(int *)p_map);
}
close(fd);
}

753 :デフォルトの名無しさん:04/09/13 12:09:27
ところでこのプログラムでmmapを使ったプロセス姦通心ができているのかどうか。
判別できないとするなら、何が間違っているのでしょうか。
childプロセスが終了した時点で当然、mmap領域のダーティーなページの内容は
当然ディスクに書き戻されているはずですが、そのことがparentプロセスが
そのページを参照することとはなんの関係もないですよね?

754 :デフォルトの名無しさん:04/09/13 13:01:36
当然?
File systemに反映させたかったらmsync(2)使え。
それからmmap(2)のonline documentをちゃんと読め。

755 :デフォルトの名無しさん:04/09/13 13:25:11
>write(fd,"aaaaaa",6);
ここは
write(fd,"aaaaaa",1); /*OK*/
write(fd,"aaaaaa",0); /*Bus Error*/

となりました。mmapというよりはファイル操作に関する基本的な
事柄のようです。O_CREATを指定して開いただけでは、ディスクリプタ
だけが作成されて、VFS(?)に対する繁栄はされないということでしょうか。
また、実際に書き換えるmmap領域よりファイルサイズが小さいと、ファイルには
繁栄されませんでした。OSはLinux-2.6.8.1 glibc-2.3.3です。

>>754
ひとまずmsyncの話は保留にして、mmapでプロセス間通信ができないという
人がいたので、素人なりにそれができると示すためのコードを書いてみただけです。
コードが間違っていて、いるのかどうかを聞いています。
上のボログラムはmsyncは呼んでませんが、ファイルには繁栄されます。

嫁というのは分ってますので、みんなが納得できるコードを示してください。

756 :デフォルトの名無しさん:04/09/13 13:25:34
>>754
お前こそちゃんと前のレスを読め。msyncなぞ使わんでも反映されるわ。


757 :754:04/09/13 13:35:16
同期的に強制するにはmsync(2)が必要ですよ。
Linux-2.6.8.1でi386なら、MAP_AUTOGROWは実装されてないでしょ。

> 上のボログラムはmsyncは呼んでませんが、ファイルには繁栄されます。

参照しているprocessがなくなったら必ず反映されるわな。VMの仕事だもんな。


758 :デフォルトの名無しさん:04/09/13 13:37:47
>>755
> mmapでプロセス間通信ができないという人がいたので、

馬鹿は無視しる


759 :デフォルトの名無しさん:04/09/13 13:40:54
>また、実際に書き換えるmmap領域よりファイルサイズが小さいと、ファイルには
>繁栄されませんでした。
これは嘘でした。勘違いもいいところ。もう少し調べてから出なおしてきます。

>>757
それは逆に言えば
・ページのリファレンスカウントがゼロなったとき
・msyncが呼び出されたとき
以外はファイルシステムには繁栄されないということでしょいうか?
まあこれこそ嫁ってやつか。

760 :デフォルトの名無しさん:04/09/13 13:41:30
>>755
> mmapでプロセス間通信ができないという人がいたので、

誰のこと?

761 :デフォルトの名無しさん:04/09/13 13:43:36
>>760
>>717とか>>741

762 :デフォルトの名無しさん:04/09/13 13:43:45
>>757
だからmsyncなぞ普通はいりませんってば。mmapしてるプロセスの実行中に
別のプロセスがそのファイルをopen/readで読んでも、ちゃんとmmapページに書
かれた内容が読まれます。あんた試してものを言いなよ。

でもってファイルサイズを越えた領域に書かれたものがファイルに反映されない
のはmmapの仕様です。msyncがどうのこうのという話ではありません。


763 :デフォルトの名無しさん:04/09/13 13:45:37
>>761
納得

764 :デフォルトの名無しさん:04/09/13 13:47:54
>>759
>>757はたぶん>>717>>741と同類(もしくは同一)なので、
相手するだけ無駄です。デンパは放置すれ。


765 :753:04/09/13 14:03:29
>>762
754=757さんは、ディスクに書き出されるタイミングを指摘しただけなので、
言ってることはあってると思います。私はmmapにつかっていたページの
参照カウントの増減があるたびにファイルに繁栄しているものだと思ってましたが、
実際はそうではなく、ページの参照カウントがゼロ、またはmsyncが呼び出されたとき、
または、何らかのバッファフラッシュ操作によるものというのが754氏の主張。
これは多分正しいでしょう。


766 :デフォルトの名無しさん:04/09/13 14:17:29
正しくない。munmapしてもすぐに書き出されると限ったわけじゃない。
だって別にプロセスに結びつけられて管理されている資源じゃなくて、
OSがキャッシュと仮想記憶の一貫としてやってるわけだから。
ま、Linuxに限れば正しいのかも知れないが。

あなた、適当にそれっぽいことを鵜飲みにしないで、ちゃんと物事を
調べる癖つけた方がいいよ。


767 :デフォルトの名無しさん:04/09/13 14:18:19
s/一貫/一環/
失礼。


768 :デフォルトの名無しさん:04/09/13 14:57:04
一応テストコードはこんなんで試しましたが、parentのsleep(30)の間に、
あんまり意味はなさそうですが、一応別プロセスということでシェルから
catでファイルを見ましたが、何度やっても/tmp/mmap.txtに繁栄されていました。
よく考えてみるとこれが実際にディスクに書き出された結果なのか、
それともpage cacheをただ読んでるだけなのかは判別できないですね。下のFigure2を見ても分るように。
http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/full_papers/silvers/silvers_html/
どうやって確かめるんだろ。

769 :デフォルトの名無しさん:04/09/13 14:58:33
int main()
{
int fd, pid;
void * p_map;
fd = open("/tmp/mmap.txt",O_RDWR|O_CREAT|O_ASYNC, S_IRWXU);
write(fd,"aaaaa",6);
pid = fork();
if(pid==0){ /*child*/
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
close(fd);
printf("child p_map == 0x%X\n",(int)p_map);
memcpy(p_map,"bbb",3);
munmap(p_map,4);
}
else if (pid>0){ /*parent*/
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
close(fd);
printf("parent p_map == 0x%X\n",(int)p_map);
wait(NULL);
printf("mmap %s\n",p_map);
sleep(30); /* ここでmmap.txtの内容を確認 */
munmap(p_map,4);
unlink("/tmp/mmap.txt");
}
}

770 :デフォルトの名無しさん:04/09/13 15:17:00
>>768
sleepするところですばやく電源抜くとか



771 :デフォルトの名無しさん:04/09/13 15:33:59
>>770
暇なんて試してみました。linux-2.4.28-pre3,glibc-2.3.3のマシンです。
ファイルはbbbaaという内容に更新されていました。このあたりはOSごとの
実装の違いが大きい話の気がしますので他の環境では当てになりません。

mmapのような複雑な機能を提供する関数の詳細まで調べるのはくどいんで
この話題終わりにします。みなさんどうも。

772 :デフォルトの名無しさん:04/09/14 00:39:31
うはあ、生半可な知識の人が多いね。


773 :デフォルトの名無しさん:04/09/14 00:41:32
>>772
お前を筆頭にな。

774 :デフォルトの名無しさん:04/09/14 00:42:42
mmapの挙動って正しく(?)はどうなの?
>>773みたいなバカはほっといて真面目に議論したいところ

775 :デフォルトの名無しさん:04/09/14 00:49:06
ええとじゃあ便乗して
同一ファイルを、別々にopenしてmmapした場合の挙動ってどうなんでしょ

というか、fork()だと同一fdだから同期されて当然?

776 :デフォルトの名無しさん:04/09/14 01:01:44
>>774-775
黙れカス

777 :デフォルトの名無しさん:04/09/14 01:10:49
たぶん同じファイルのメモリ上のキャッシュは1つしかなくて、
mmapされるのはその同じメモリだろうから自動的に同期されて
見えそうな気がする。


778 :デフォルトの名無しさん:04/09/14 01:19:54
>>777
想像で語るな

779 :デフォルトの名無しさん:04/09/14 07:35:39
>>775 どうもなりませんでした。
[プロセステーブル項目]->[ファイルテーブル]->[vノードテーブル]のうち
fork直後に頭二つの項目を共有しているかどうかはmmapには何の関係もないようです。

int main()
{
int fd, pid;
void * p_map;
fd = open("/tmp/mmap.txt",O_RDWR|O_CREAT|O_ASYNC, S_IRWXU);
write(fd,"aaaaa",6);close(fd);
pid = fork();
if(pid==0){ /*child*/
fd = open("/tmp/mmap.txt",O_RDWR|O_CREAT|O_ASYNC, S_IRWXU);
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
close(fd);
printf("child p_map == 0x%X\n",(int)p_map);
memcpy(p_map,"bbb",3);
munmap(p_map,4);

}
else if (pid>0){ /*parent*/
fd = open("/tmp/mmap.txt",O_RDWR|O_CREAT|O_ASYNC, S_IRWXU);
p_map = mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
close(fd);
printf("parent p_map == 0x%X\n",(int)p_map);
wait(NULL);
printf("mmap %s\n",p_map);
sleep(30); /* ここでファイル内容を確認 */
munmap(p_map,4);
unlink("/tmp/mmap.txt");
}
}

780 :デフォルトの名無しさん:04/09/14 08:20:29
>>709の話だけど、結局mmapのためにファイルのサイズを調整しなくては
ならないなら、WindowsのようにCreateFileMappingのような関数が
あったほうがスマートな感じがしませんか?
論理的なファイル(FS)、マッピング対象オブジェクト、実際のビュー
と三つの観点で綺麗に分けることができる。

781 :デフォルトの名無しさん:04/09/14 08:51:55
逆にWindowsもCreateFileMappingの関数を通常のファイルの読み書きに対しても
適応すべきだったかと。その方が分りやすい。
論理的なファイルに対するハンドルで、いきなり読み書きするのは変。

782 :デフォルトの名無しさん:04/09/14 09:17:29
>>780
スマートだと思うよ。

a)デバイスをシステムのメモリ空間に割り付ける
b)システムのメモリ空間をプロセスのメモリ空間からみえるようにする

a)とb)が明確に分かれていれば、
a)の結果の共有→b)した複数プロセスからの見え方の同期
が素直に理解できるし、>>775のような悩みを持たずにすむ。

abを一緒くたにしちゃってるのは変。

783 :デフォルトの名無しさん:04/09/14 09:23:42
「システムのメモリ空間」って何なんだよ?

784 :デフォルトの名無しさん:04/09/14 09:31:23
キチガイはスルーの方向で

785 :デフォルトの名無しさん:04/09/14 09:36:27
>>781はよく考えてみれば、ReadFile/WriteFileなんかの関数は
UNIXの影響下にあるOSとの互換性を意識して作られたものなのかなって
気がしてきました。
ディスクキャッシュも最終的にはpage cacheとして一元管理されているのなら
Mapして操作することとなんら違いはないはず。

ところでUNIXにおいてmmapでファイルの読み書きするのと、read/writeとでは
パフォーマンスに違いはあるんでしょうか?どこかによいベンチの結果とか
ありますか?

786 :デフォルトの名無しさん:04/09/14 09:45:14
当然mmapの方が早い。
なぜならread/writeではカーネル空間→ユーザ空間、またはその逆の
メモリコピーが発生するから、ずっとコストが高い。



787 :デフォルトの名無しさん:04/09/14 10:47:28
出始めたばかりのSVR4のcat(1)は、
# Sunが作ってUI軍団に配布した奴ね。
mmap(2)で実装されていた。遅かった。

まあ、VMの実装によっても違うと思うが、
mmap(2)ではmemoryをたくさん食ってしまうから遅い、
buffering I/Oでは、processのmemory消費量が少なく、
disk I/Oがうまくinterleaveされるって事だったと思う。

今時の単一仮想記憶だと>>786なのかなあ。
Linuxはそうなんじゃないかと思うが、
FreeBSDなんかはdisk I/Oを特別に扱ってないですか?




788 :デフォルトの名無しさん:04/09/14 15:47:28
memoryやinterleave、それにprocessはカタカナで書けよ。

789 :デフォルトの名無しさん:04/09/14 15:51:01
>>788
YOUはSHOCK世代だから。

790 :デフォルトの名無しさん:04/09/14 16:29:52
昭和のカタカナ世代は横文字が苦手です

変数名や関数名にローマ字多用するのが特徴です

791 :デフォルトの名無しさん:04/09/14 17:57:15
Sun、「Solaris 10」をオープンソースに――年内にプロジェクト発足へ
http://www.itmedia.co.jp/enterprise/articles/0409/14/news030.html

792 :デフォルトの名無しさん:04/09/14 22:08:29
そしてJavaをオプソに。その後には何も残らなかった・・・

793 :デフォルトの名無しさん:04/09/14 23:08:23
NFSなファイルのmmapってどうなんすか?

794 :デフォルトの名無しさん:04/09/14 23:37:00
どうってなにが?

795 :デフォルトの名無しさん:04/09/14 23:57:31
アフォはスルーの方向で。

796 :デフォルトの名無しさん:04/09/15 00:23:33
>>786
> 当然mmapの方が早い。
> なぜならread/writeではカーネル空間→ユーザ空間、またはその逆の
> メモリコピーが発生するから、ずっとコストが高い。

いや、必ずしもそうとは限らない。

mmapではメモリコピーの代わりにページフォールトが発生することになるが
こいつのコストが(特に最近のプロセッサでは)馬鹿にならない。
一方、メモリコピーの場合、コピー元データがL1キャッシュに載っていたりすると
コストが圧倒的に小さくなるから、メモリコピーの回数とパフォーマンスは
必ずしも反比例するわけではない。

てことで、以下のメールのように、条件によってはmmapよりread/writeの方が
速くなることもある。
ttp://lists.freebsd.org/mailman/htdig/freebsd-current/2004-June/029521.html

797 :デフォルトの名無しさん:04/09/15 04:23:41
ページフォルトもsyscallと同じくらいのコストで効いてくるだろうとは
思っていたけど、うーん。
IO-boundとCPU-boundで変わってくるのか。
キャッシュが効いてくるという話なら、バッファの大きさでも変わりそう。

MADV_SEQUENTIALはmanを読むと先行するページを早くページアウトするようにす
るという後ろ向きの最適化だけど、ページフォルトを減らすべく一度に複数ペー
ジをまとめてページインするようにはできないものだろうか。今の話を素直に解
釈すると、これで何か不都合がなければそれなりに効果がありそうに思うのだが。



798 :デフォルトの名無しさん:04/09/15 06:48:04
ページというのは、ファイルのサイズを頭から4kなり8kなりの
CPUのページ単位で区切って、論理的にメモリに割り当てるんでしょうか?
もしそうなら、mmapするときはページ境界を意識して使う必要がありますよね。
というか、page cache一元管理を前提と考えるなら、ファイル構造やユーザー
データなどありとあらゆるデータが、ページ境界を意識すべきということなのかな?

mmap,read/writeの話は結局どういった使い方をするのかっていうのにかかってる
ような。mmapを使うなら、極力フォルトの発生しないようにするのは、ユーザー側で
意識することだろうし。read/writeに関してはカーネルがページフォルトを
抑えるよう、特別にバッファリングしてくれるのかもしれないけど。

ちなみに関係ないですが、インテルのCPUには4MB単位、つまりページディレクトリだけの
ページング方式があったように思いますが、あれじゃWindowsやUNIXといったOSは
(プロセス間通信をmmapで一元管理するのはMach由来なんでしたっけ)
まともに動きそうにないですね。どうなんでしょう。

799 :デフォルトの名無しさん:04/09/15 06:56:58
まあ憶測だけで、間違った考えを持ちつづけてるのもよくないから
ここいらでそろそろ真面目にソースを読んでおくべきということか。

800 :デフォルトの名無しさん:04/09/15 08:45:24
>>798
> もしそうなら、mmapするときはページ境界を意識して使う必要がありますよね。

$ man mmap

801 :デフォルトの名無しさん:04/09/15 10:07:13
>>800
>ファイルはページサイズの整数倍の領域にマップされる。
>サイズがページサイズの整数倍でないファイルの場合、
>マップ時に残りの領域は 0 で埋められ、.......

1) マップの単位はページ境界に整列
2) ファイルも0byte目からページ単位に区切って、それぞれページ境界にぴったりとそろえる。
という二つの意味にとっていいんでしょうか。1は当たり前のことですが。
straceによりlibc(i386)がマップされる様子を見てみると

open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200^\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1243888, ...}) = 0
old_mmap(NULL, 1254052, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001d000
old_mmap(0x40145000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40145000

一つ目のmmapでlibcのファイル全体を、0x4001d000から1254052
(0x1322a4≒0x133000=307ページ)バイト分マップ
二つ目のmmapでおそらく.data領域となるであろう部分をPROT_WRITE,MAP_PRIVATEを指定して、
0x40145000(一つ目のマップ領域中の296ページ目、ファイル中の0x127000=295ページ目。
一つずれているのはなぜだろう?)から32768(0x8000=8ページ)バイト分マップ
という理解であってますか?これなどを見るとファイルの先頭は一応、
ページ境界に一致させてるように見えます。しかし、、リンカはあんまりページ境界を
意識してELFファイルを構成してるようには見えないですね。ヘッダのような実行時に
不要なデータは、ページ境界を意識するならどこか一つにまとめておくべきでしょうね。

ところで、二つ目のmmapは一つ目のものを上書きしてるように見えます。
ページ境界にはもちろん整列してますけど。こういうのもありなんですかね。

802 :デフォルトの名無しさん:04/09/15 10:17:40
ELFの規格にヘッダの場所が定義されているので、
リンカの問題というよりは規格自体の話ですね。訂正。

803 :デフォルトの名無しさん:04/09/15 14:39:33


804 :デフォルトの名無しさん:04/09/15 15:06:13
みんな賢いなあ
何言ってっか全然分かんないや

805 :デフォルトの名無しさん:04/09/15 23:35:50
趣味でプログラムを書いている者ですが、X lib の質問があります。ここで
お尋ねしても宜しいでしょうか? UTF-8 locale 関係です。お願いします。

806 :デフォルトの名無しさん:04/09/15 23:36:58
>>805
ごちゃごちゃ言ってないでさっさと質問しろ

807 :デフォルトの名無しさん:04/09/15 23:38:23
UNIX系スレはこういう突っ込んだ話されないからもっとやって欲しい
つーかmanが貧弱すぎ
MSDNみたいなのが欲しい
もちろんサンプル付きで


808 :デフォルトの名無しさん:04/09/15 23:42:48
Xlib のスレッドあったべ。

809 :デフォルトの名無しさん:04/09/15 23:45:12
805 です。お言葉に甘えて。
(前置き)
Fedora Core 向けに、自作ソフトを UTF-8 対応しました。ところが、
動作が eucJP locale に比べて激しく遅いのです。で、何に時間を
食っているのか調べたら、XCreateFontSetでした。0.02 sec くらい
だったのが、3 sec くらいかかっています。
(で、質問です)
font load を早くするにはどうしたら良いのでしょうか?
見た感じでは、大量のfontをloadしているのではないかと思います。
できれば、iso10646-1 の font 一個のみで済ますようにしたいの
ですが…。
宜しくお願いします。

810 :デフォルトの名無しさん:04/09/17 02:16:38
fontconfig叩いたら?
何せ,古いインターフェースだもんでな。

811 :デフォルトの名無しさん:04/09/17 07:22:51
>>809
$ cat ~/.xserverrc
-deferglyphs all

812 :809:04/09/17 21:14:09
ありがとうございます。
>> 810 さん。ちょっと覗いてみましたが、すぐには理解できなかったので、
勉強してから試してみます。
>> 811 さん。試してみました。効きました。時間は半分になりました。
今のところ、
・Font 指定の曖昧性を減らした。(3sec -> 1sec)
・server option に -deferglyphs を設定した。(1sec -> 0.5sec)
さらに、ですが、xterm は iso10646-1 のフォントのみで表示できている
ので、これも参考にしてみたいと思っています。

813 :デフォルトの名無しさん:04/09/17 21:29:33
>>810
保守もされてないし
これでプログラミングしようとする奴の気が知れないよね

814 :デフォルトの名無しさん:04/09/17 22:37:53
>>813
script kiddyのくせに何を言う。


815 :デフォルトの名無しさん:04/09/17 22:48:16
>>814
quiche eaterのくせに何を言う。

816 :デフォルトの名無しさん:04/09/17 22:56:42
>>813
大丈夫か?

817 :デフォルトの名無しさん:04/09/17 23:24:29
>>816
なにが?

818 :デフォルトの名無しさん:04/09/18 00:03:00
おつむ

819 :デフォルトの名無しさん:04/09/18 00:24:56
てーんてん

820 :デフォルトの名無しさん:04/09/18 00:51:22
>>813
もはや図星を点かれて何も言い返せないな・・・。
全くその通りですが何か?

個人的にUNIXは人を不幸にするOSだと思う。
さっさと死滅してくれると業界も少し平和になるんだが。

821 :デフォルトの名無しさん:04/09/18 01:01:58
Plan9にそろそろ移行する?

822 :デフォルトの名無しさん:04/09/18 01:03:24
MINIXでいいじゃんかよ

823 :デフォルトの名無しさん:04/09/18 01:13:23
そこで GNU Hurd ですよ.

824 :デフォルトの名無しさん:04/09/18 07:28:49
>>820
WinSockの理不尽なバグや意図角プロセスのリソースリークがシステム全体のダメージになったりするのはプログラマを幸せにしますか?


825 :デフォルトの名無しさん:04/09/18 10:11:38
てゆーか普通に考えたら、
定期的に再インストールしないとパフォーマンスが落ちたり
不安定になったりするようなOSは、ものすごい欠陥品だよねぇ。
みんなよく使ってるよなあ。

なんてことをうぃんどーずから書き込んでみる。

826 :デフォルトの名無しさん:04/09/18 12:40:51
まだwin9x使ってるの?

827 :デフォルトの名無しさん:04/09/18 13:02:16
おれときどきfreebsd再インストールしてるよ
やっぱおかしくなるし


828 :デフォルトの名無しさん:04/09/18 13:45:56
>>827 はときどき rm -rf * ~ とかやっているおっちょこちょいさん

829 :デフォルトの名無しさん:04/09/18 13:48:52
普通はおかしくなった時点で、その原因を調べると思うんだが…

830 :デフォルトの名無しさん:04/09/18 14:00:46
>>829
コストの差だね。
原因調べるよりも、まず再起動した方が安い場合も多いよ。

831 :デフォルトの名無しさん:04/09/18 14:15:59
再インストールの話題だと思ってたのはオレだけですか?

832 :デフォルトの名無しさん:04/09/18 14:17:42
再インストールも楽になってるし、原因を調べるなんて
>>830のいうようにコストの面からしてアホらしくなってるしな

833 :デフォルトの名無しさん:04/09/18 14:25:28
原因を調べなくてはいつまでたっても、同じようなことを繰り返すわけだが。

834 :デフォルトの名無しさん:04/09/18 14:37:59
繰り返すようになってから対策を練ればいい。

835 :デフォルトの名無しさん:04/09/18 14:47:06
ってことで >>827 は対策を検討すること。

836 :デフォルトの名無しさん:04/09/18 16:59:26
頭の悪い人:
・使い方がアホだからこそおかしくなる。これが根本原因
・お仕着せのままで満足してしまうので再インストールがコストが低いと思ってる
・アホだから原因を調べられないのにコスト比較のふりをして現実から逃避
→そんなあなたにピッタリなのは……おせっかい設定てんこもりのVine Linux
お仕着せをありがたがって使いましょう、好みと違っても文句禁止、質問は犬板で。
まちがってもLinux板から出てきちゃだめ

頭のいい人:
・理解して使ってればそもそも変な使い方しないからそうそうおかしくならない
・インストール後様々なカスタマイズやコンピュータにさせる仕事の設定を行う
ので再インストールのコストは低くない
・おかしくならないから長いこと使う、自然カスタマイズも進む
→そんなあなたは*BSDでもSolarisでもお好みでどうぞ、どれでも大丈夫


837 :デフォルトの名無しさん:04/09/18 17:08:06
そもそもUNIXで再インストールが必要になる状況ってどんなの?
Windowsだって、システモの情報がある程度まで公開されていれば
再インストールなんて必要ない。ただWindowsは複雑だから面倒くさそう。


プログラミングに関係ない話題はよそでお願いします

838 :デフォルトの名無しさん:04/09/18 17:10:24
アフォはスルーの方向で。

まあ再インストールでいいんでねえの?
バックアップもM$のクソOSに比べれば簡単なんだし。
なんでこんなに拒絶反応があるのか理解に苦しむ。

839 :デフォルトの名無しさん:04/09/18 17:15:20
つか、再現不能で上がってきた不具合を何日も調査して結局ハード
のせいだったとわかった時には。。。 _| ̄|○

840 :デフォルトの名無しさん:04/09/18 17:25:48
バックアップのリストアは普通は再インストールとは言わないよ。
問題が内在していないのはいつの分までかを簡単に調べられたら
バックアップのリストアでもいいけど、普通はわざわざそんなこと
せずに動いてるシステムで原因を修正しておしまい。



841 :デフォルトの名無しさん:04/09/18 17:27:15
>>838は自分をスルーしろと言う珍しい香具師だな。



842 :デフォルトの名無しさん:04/09/18 17:32:46
OSから再インストールってのは少ないが、アプリケーションの再インストール
はたまにあるな。なにしろ動いてるものなんで、ゆっくり原因解析してる暇は無い。

843 :デフォルトの名無しさん:04/09/18 17:44:53
侵入の形跡が発見されたらOSの再インストールが必要だと思います。

844 :820:04/09/18 18:02:58
なんか大漁ですが
釣りのつもりはありませんでした
ごめんなさい
やっぱUNIXは不幸なOSなのか
みんな苦労してそうだな〜

845 :デフォルトの名無しさん:04/09/18 18:21:28
UNIXerたるもの、システムのすべてを把握しているものだ。
ファイルの一つ一つのpermissionもチェックし、
書き換わらないようなファイルの置き場と、
よく書き換わるファイルの置き場を区別するものだ。


・・・とか言い出しそうでキモい

846 :デフォルトの名無しさん:04/09/18 18:24:05
そのうち犬糞にシェア食われて死滅するでしょ。
ほっとけよ。

847 :デフォルトの名無しさん:04/09/18 19:07:21
ここは UNIX"プログラミング"質問すれ ですよ。

おまえらまとめてよそでやれ。

848 :デフォルトの名無しさん:04/09/18 19:28:19
>>845
え? まともな管理者ならファイルのパーミッションはチェックしていて当然だろ。
*BSDだとかいくつかのLinuxのdistributionだとsetuidされたファイルの
変更をcronでチェックするようになってるし、マルチユーザ環境なら
だれでも書けるファイルやディレクトリはじめパーミッションの確認は必須だろ。
Windowsと違ってデフォルトが安全サイドだから要注意対象はたかが知れてる。

後半に至っては/varの存在意義を否定してるな。

>>844
言葉が抜けてる。
UNIXは「バカにとっては」不幸なOSかも知れない
「おバカの仲間は」みんな苦労してそうだな〜


849 :デフォルトの名無しさん:04/09/18 19:31:50
UNIXに慣れることができなかった奴は、UNIXが分らなかったんじゃなくて、
OSそのものが分らなかったんだよ。それをUNIXが古臭いということに摩り替えて
ごまかす。多分そういう奴はWindowsのことも大して分ってない気がするけどね。

850 :デフォルトの名無しさん:04/09/18 19:34:41
>>845
ファイル一つ一つについてサイズパーミッションと変更時刻を読み上げて
資料と照らし合わせるってのは実際にやるよ。

851 :デフォルトの名無しさん:04/09/18 19:38:17
UNIXは馬鹿にとって幸福なOSだと思っていたが違うのか

852 : ◆FIcNi4f8js :04/09/18 20:01:50
UNIXは馬鹿には使えないOSです

853 :デフォルトの名無しさん:04/09/18 20:02:57
(・∀・) うわーい、ひゃっほー!

854 :デフォルトの名無しさん:04/09/18 20:03:54
ドライバの一つも書けない奴がUNIXを使えるとは言いません。

855 :デフォルトの名無しさん:04/09/18 20:47:13
うわー
マジキモ

856 :デフォルトの名無しさん:04/09/18 20:51:09
ドライバ書けるけどUNIXあまりよくしらナイヨ

857 :デフォルトの名無しさん:04/09/18 21:48:59
>>856
わしも。
仕事が組み込み系だし。
割とありがちでないの?

858 :デフォルトの名無しさん:04/09/18 22:09:29
組み込みエンジニアはこの先引く手あまただろうな。うらやましい。
おれも勉強するぞ!

859 :デフォルトの名無しさん:04/09/18 22:55:29
そうやって俺をイラつかせて、何をしたいんだ。
俺に恨みでもあるのか。それとも人をからかうのが好きなのか。
どちらにしても、お前は悪意をもって人を傷つけようとした。
こういう事はこれで最後にしろ。

860 :デフォルトの名無しさん:04/09/18 23:33:03
>>859
流行っちゃうよそんなにあちこち貼ったら。
書いたひとはどっちかっていうと被害者なのに。


861 :デフォルトの名無しさん:04/09/19 00:49:37
<事業者><送信者>
東京都新宿区西新宿2-3-15大山ビル2F
55ソフトシステムズ
配信停止の場合の返信先 softsoft55@hotmail.com
配信停止は24時間後に反映されます。
当配信は送信に関する特定商表示義務規定に則り送信しています。
------------------------------------------------------------
以下のビジネスソフトを激安販売します
・Windows 系 Os Office 等  全て 6割〜8割 引
・Adobe 系 Os Photoshop 等 全て 8割〜9割 引 
・CADソフト 及び ビジネスソフト  全て 6割〜9割 引
その他 合計280種類のビジネスソフトがあります。
サポート付きですので納得安心価格です。
郵便代引きで 即日急送します
くわしくは
http://www.55soft.net/
をご覧ください
 == 55Soft.net は、ビジネスソフトの安売り王です ==

862 :デフォルトの名無しさん:04/09/19 12:55:50
メガネをかけたやつは覗きマニアばっかりだな

863 :デフォルトの名無しさん:04/09/20 08:09:59
>>850
UNIXの頭のいいやつなら
サイズパーミッションと変更時刻も変更せずに、プログラムを
書き換えることもできるだろ


864 :句読点書けないバカをサマージャンボする俺 ◆9NQzQ21lx. :04/09/20 08:28:41
>>863


865 :デフォルトの名無しさん:04/09/20 08:52:44
>>864
いつまで夏のつもりだ池沼

866 :デフォルトの名無しさん:04/09/20 08:55:02
季節もわからない人に言われても、ねぇ。

867 :デフォルトの名無しさん:04/09/20 11:11:37
>>863
通常不可能。
root権限を奪えば可能性はありますが、それでも
例えばFreeBSDではその可能性のある操作を禁止できます。


868 :デフォルトの名無しさん:04/09/20 12:24:28
今年は一年夏でしたとか。

869 :デフォルトの名無しさん:04/09/20 12:37:13


870 :デフォルトの名無しさん:04/09/20 14:58:44
CPUの判別方法を教えてください

871 :デフォルトの名無しさん:04/09/20 15:09:55
popen("uname -m", "r");

872 :デフォルトの名無しさん:04/09/20 15:19:58
unameはunix標準ではありませんが?バカ?

873 :デフォルトの名無しさん:04/09/20 15:35:21
使えない環境に当たったこと無いな。

874 :デフォルトの名無しさん:04/09/20 16:00:15
#include <sys/utsname.h>
int uname(struct utsname *name);


875 :デフォルトの名無しさん:04/09/20 16:26:42
CPUの判別方法なのに。
ヴァカ?

876 :デフォルトの名無しさん:04/09/20 17:03:09
OSを特定せずにCPUの判別方法なんて尋ねる方がバカ。
unameをPOSIXが定めていることを知らないで暴れてる>>872もバカ。


877 :デフォルトの名無しさん:04/09/20 18:26:42
>>870
config.guessとか。中を覗くといろいろやってるね。

878 :デフォルトの名無しさん:04/09/20 19:07:37
machdep.c あたりにある identifycpu() みたいな話を言ってるんじゃないの?

879 :デフォルトの名無しさん:04/09/20 22:54:46
職場に「昔の Unix はプログラム終了前に必ず free しないと malloc などで獲
得したメモリは開放されない」と言っている先輩がいます。これは本当ですか?

880 :デフォルトの名無しさん:04/09/20 22:56:49
昔のUnixは知りませんが本当です

881 :デフォルトの名無しさん:04/09/20 23:12:08
>>879
free on exit fj でぐぐればたぶん出てくるよ。

882 :デフォルトの名無しさん:04/09/20 23:13:24
その話題はタブーです。

883 :デフォルトの名無しさん:04/09/20 23:36:41
>>879
資源管理がいい加減なOSならリークするでしょう。

どちらにせよ、

「プロセス中で確保したもんは必ず手動で閉じなされ。」

と言うのは肝に銘じてた方がいいっす。

884 :デフォルトの名無しさん:04/09/20 23:56:54
>>879
どちらにせよ、

「mallocしてfreeしないと云々。」

というのを耳にしたら一目散に逃げるべしと言うのは肝に銘じてた方がいいっす。

885 :デフォルトの名無しさん:04/09/20 23:59:50
取りあえず閉じる癖付けとかないと、単発確保のメモリはともかくデーモンのループで確保して解放しないとか言う
悲しいバグを組み込む率が上がりそうだ。

886 :デフォルトの名無しさん:04/09/21 00:03:06
最近のGCのある言語なら勝手に解放してくれるし
プロセスも終了時にリソースの解放をしてくれる。
ただし自分で明示的に解放を指示になければならない
ケースも存在しないわけではないので
大切なのは盲目的教条主義に陥らずに
その都度最適な方法を判断することだ。

887 :デフォルトの名無しさん:04/09/21 00:03:56
おお、今度はmalloc & freeネタか?
香ばしいねえ

とはいえ、unixerたるもの、OSから借りた資源はしっかり返すものだな。
これをわかってないド素人がunixerを気取ってるのは、正直イタい。

888 :デフォルトの名無しさん:04/09/21 00:04:27
さっそくsageも知らないヴァカが湧いてきました

889 :デフォルトの名無しさん:04/09/21 00:06:09
>>886
いや、ファイルとかセマフォとか。<資源
GCのある言語はデストラクタの実行タイミングが曖昧なのでスマートポインタのような使い方はお勧めしない。

890 :デフォルトの名無しさん:04/09/21 00:07:15
Javaでファイルが開けなくなるアレですね

891 :デフォルトの名無しさん:04/09/21 00:08:11
>>886
>その都度最適な方法を判断することだ。

解放しないのが適切な場合ってどんなの?
移植性は下がるしヒューマンエラーの温床となるし、良い所ってぱっと思いつかないんだけど。

892 :デフォルトの名無しさん:04/09/21 00:08:18
sage荒らしを発見しますた

893 :デフォルトの名無しさん:04/09/21 00:11:56
そのプログラムのライフサイクルによっては
イチイチfreeしてまわるよりはexitしてもらったほうが
ソフトウェア製造コストとしては安いかもね

それを最適と呼ぶかどうかは状況によるなあ

894 :デフォルトの名無しさん:04/09/21 00:13:31
>>891
OSが適切に処理してくれるのに、わざわざ自分で処理を書いたほうが
ヒューマンエラーの元になることがわからないのか。

895 :デフォルトの名無しさん:04/09/21 00:16:37
全部879の自作自演かな

896 :デフォルトの名無しさん:04/09/21 00:20:28
この宗教戦争ネタでfj.lang.cで盛り上がってたのって大昔だろ
いやすでにfj.comp.lang.cになってたか

今更食いついてる香具師って何者?
この話題に関わっても無知蒙昧をさらすだけよ、いろんな意味で。
すでに1000000辺ぐらい繰り返された論争の、低レベル縮小ミニマム再生産版
見せられて喜ぶ奴なんていやしないんだから。

897 :デフォルトの名無しさん:04/09/21 00:21:41
>>896
輪廻転生

898 :デフォルトの名無しさん:04/09/21 00:24:20
古典芸能ですよ。

899 :デフォルトの名無しさん:04/09/21 00:25:15
20レス稼いだ

900 :879:04/09/21 00:29:42
なんか大漁ですが
釣りのつもりはありませんでした
ごめんなさい
やっぱUNIXは不幸なOSなのか
みんな苦労してそうだな〜


901 :デフォルトの名無しさん:04/09/21 00:33:11
不幸なのはユーザーだけだから

902 :デフォルトの名無しさん:04/09/21 00:33:26
>>900
リソースリークが即死を意味するようなWindowsよりかは幸せです。

903 :デフォルトの名無しさん:04/09/21 00:35:07
>>902
はぁ?

904 :デフォルトの名無しさん:04/09/21 00:36:07
>>903
犬糞や海栗糞が窓叩く場合Win98以前をターゲットにするのがマナーなんだよ。

905 :デフォルトの名無しさん:04/09/21 00:37:10
関係ないはなししは他所でおねがいします。

906 :デフォルトの名無しさん:04/09/21 00:37:59
>>904
それがWin2kだったりするから質が悪いんだと。
まぁ、俺のプログラムの質が悪かったと言えばそれまでだが。

某プラントシステムがぐらぐらになったよ。

907 :デフォルトの名無しさん:04/09/21 00:38:39
Windowsの場合、メモリはリークしてるように見えてるだけ

908 :デフォルトの名無しさん:04/09/21 00:38:55
だからさC#やJavaが台頭してきた時代に
前世紀の遺物であるfj.comp.lang.cを楯に思考停止に陥るのは
いかがなものかと言ってるわけさ。

909 :デフォルトの名無しさん:04/09/21 00:39:36
>>907
そう言われても俺の糞プログラムにはmallocはあってもfreeはない。

910 :デフォルトの名無しさん:04/09/21 00:39:37
いみふめー

911 :デフォルトの名無しさん:04/09/21 00:40:39
>>908
ネイティブな言語が減ってきて暮らしにくい世の中になったなと。
豊富な資源がアル前提でRADするには最高の環境なんだけどね。


912 :デフォルトの名無しさん:04/09/21 00:42:34
>>908
盾にって言われても、fjでの議論の結論知らないんだけど
どっちが勝ったんだっけ?

913 :デフォルトの名無しさん:04/09/21 00:44:04
>>912
そんなことはどうでもいいんだよ。
いったんリセットして僕たちは0から話し合うべきなんだ。

914 :デフォルトの名無しさん:04/09/21 00:44:09
結論なんてでるわけないじゃん。
自分でOS作って俺環境こそが唯一正しいと
主張するならある程度の妥当性はあるだろうけど。

915 :デフォルトの名無しさん:04/09/21 00:45:17
>>913
正解。
昔と今では状況も違えば常識も違う。

ムーアの法則が未だに有効であることからも状況が少なからず変わっていることがおわかり頂けるだろう。

916 :デフォルトの名無しさん:04/09/21 00:45:24
>>905が無視されているようなので一応言っておこう。

はなししってなんですか。

917 :デフォルトの名無しさん:04/09/21 00:46:15
>>914
linuzの性格がもう少し悪ければ・・・と言う話ですね?

918 :デフォルトの名無しさん:04/09/21 01:44:11
>>889
> GCのある言語はデストラクタの実行タイミングが曖昧なので

みんなJava風なわけではない。




919 :デフォルトの名無しさん:04/09/21 01:46:02
>>912
fjや2chの議論に結論はない。まとめがある場合はある。
free on exitはまとめがあったはず。

920 :デフォルトの名無しさん:04/09/21 02:46:47
ちゃんと解放しろっての
リソース=メモリってわけじゃないし



921 :デフォルトの名無しさん:04/09/21 02:57:17
直後に exit することがわかってんなら必要ねえっての
明示的に開放しないと問題のあるリソースならともかく

922 :デフォルトの名無しさん:04/09/21 02:59:54
1000までに決着つけようぜ

923 :デフォルトの名無しさん:04/09/21 03:01:24
その前にgotoの是非について決着をつけろ

924 :デフォルトの名無しさん:04/09/21 03:02:16
goto使うやつは馬鹿

925 :デフォルトの名無しさん:04/09/21 03:05:28
goto使わないやつはマヌケ

926 :デフォルトの名無しさん:04/09/21 03:06:32
goto使えないやつは馬鹿

927 :デフォルトの名無しさん:04/09/21 03:06:51
うひょーーーーーさっそく知将が発生したっっっ

928 :デフォルトの名無しさん:04/09/21 03:07:28
goto >>927;

929 :デフォルトの名無しさん:04/09/21 03:21:17
SIGPLANではインデントの話は禁止です。

930 :デフォルトの名無しさん:04/09/21 03:49:47
goto HEAVEN;

931 :デフォルトの名無しさん:04/09/21 04:03:24
>>912
俺はホントに最初の頃の議論しか見てないが、印象としては

UNIX系のマトモなHosted Environmentを主に使ってる人→
そんなのカーネルにまかせろや。free()しないと回収できないような
システムなら、killもできないってこったぜ
仮想メモリ管理をちゃんとやってるOSでfree on exitなんざアホの極み

主に組み込み系エンジニア、またはWin16あたりのクソOSユーザだった人→
回収しろったらしろ。

な感じと記憶しているが、確実にいえるのは「必要な場合ならやれ」。それだけなら
当たり前で、そこに移植性やらコーディングスタイルやら思想やらの問題を
持ち出す香具師がいるから宗教戦争になる。
ただ、業務系では意外に頭固い人多いんだよね。free on exitをしないのは
だらしが無いとか何とか。「それが適切か」ではなく、「そもそもそういう
スタイルが許せない」人が多い。


932 :デフォルトの名無しさん:04/09/21 04:54:25
gogo HEAVEN;


933 :デフォルトの名無しさん:04/09/21 05:13:19
気になる人は
atexitに登録した関数内で開放するということでFA?

934 :デフォルトの名無しさん:04/09/21 05:16:55
Ruby!

935 :デフォルトの名無しさん:04/09/21 05:18:03
Rubyはリークしまくるから業務には使えないと思う。
いつ安定するんだか。

936 :デフォルトの名無しさん:04/09/21 05:20:45
Ruby.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>UNIX

937 :デフォルトの名無しさん:04/09/21 05:23:00
↑なんか最近怖くなってきたw

938 :デフォルトの名無しさん:04/09/21 06:18:19
elisp>>>>>>>>>>>>>>>>> Ruby

939 :デフォルトの名無しさん:04/09/21 07:04:31
Python >>>>>>> |越えられない壁| >>>>>>>>>>>> Ruby

940 : ◆FIcNi4f8js :04/09/21 08:54:52
Cはリークしまくるから業務には使えないと思う。
いつ安定するんだか。


941 : ◆FIcNi4f8js :04/09/21 08:55:29
Pythonはリークしまくるから業務には使えないと思う。
いつ安定するんだか。

942 :デフォルトの名無しさん:04/09/21 09:03:24
CPUはジャンプしまくるから業務には使えないと思う。
いつ安定するんだか。

943 :デフォルトの名無しさん:04/09/21 09:14:31
電子は振動しまくるから業務には使えないと思う。
いつ安定するんだか。

944 :デフォルトの名無しさん:04/09/21 09:18:59
お前ら2chやりすぎるから業務には使えないと思う。
いつ仕事するんだか。

945 :デフォルトの名無しさん:04/09/21 09:24:00
宇宙は膨張しまくるから業務には使えないと思う。
いつ安定するんだか。

946 :デフォルトの名無しさん:04/09/21 11:25:39
アソコが膨張しまくるから女にはぶち込めないと思う。
いつ発射するんだか。


947 :デフォルトの名無しさん:04/09/21 12:00:53
せめてageろ。

948 :デフォルトの名無しさん:04/09/21 13:38:34
>>946
俺と(ry

949 :デフォルトの名無しさん:04/09/21 17:05:02
>>912
2000年頃のやつなら
http://groups.google.co.jp/groups?hl=ja&lr=&ie=UTF-8&inlang=ja&c2coff=1&selm=95cjf3%24il3%241%40news.tut.ac.jp
これが結論でいいと思う


950 :デフォルトの名無しさん:04/09/21 18:02:02
結論はないという結論

951 :デフォルトの名無しさん:04/09/21 20:05:11
メジャーなオプソプロジェクトでfreeしていないものを教えてください。
またfree不要論者は最大何人月、何行くらいのプロジェクトでfreeを省きましたか?

952 :デフォルトの名無しさん:04/09/21 20:15:52
Ruby>>>>>>>>>>>>>>>>>>>>>>>>>>> free

953 :デフォルトの名無しさん:04/09/21 22:16:42
>>951
全く意味不明なのだが。


954 :デフォルトの名無しさん:04/09/21 22:34:50
ニゲタ━━━━(゚∀゚)━━━━ッ!!

955 :デフォルトの名無しさん:04/09/21 22:36:48
オープンソースプログラムで、必要なfreeを行っていないプログラムを知りたいんでしょ。

956 :デフォルトの名無しさん:04/09/21 22:38:32
>>955
何か意味あるの?

957 :デフォルトの名無しさん:04/09/21 22:40:24
FreeBSDの/usr/bin配下調べればありそうだけど面倒だからやらないw

958 :デフォルトの名無しさん:04/09/21 22:49:03
いまちらと見たが、freebsdのcatはmalloc()を一回しててfree()してない。
プロセスの実行中に何度も実行され、ワーキングセットを着実に増加させて
いくような性質ではないmalloc()なら、わざわざfree()してないプログラムは
多いだろう。
典型的なのが、初期化処理内でのmalloc()ね。

959 :デフォルトの名無しさん:04/09/22 01:36:16
必要なfreeはやるべき。それは誰も否定してない。
必要じゃないfreeをやらなくていいって話

960 :デフォルトの名無しさん:04/09/22 09:20:03
そしてすべての free が必要だと主張する人がいて以下 loop.

961 :デフォルトの名無しさん:04/09/22 09:42:08
そんなヤツはアホなので即刻 exit

962 :デフォルトの名無しさん:04/09/22 09:54:15
賢い人はこういうドキュンな話題には触れないよな

963 :デフォルトの名無しさん:04/09/22 11:38:56
賢い人はちゃんと全部freeするからな

964 :デフォルトの名無しさん:04/09/22 11:46:18
>>963
禿同。
みんな引きオタの実績0の脳内理論に釣られすぎだよ。

965 :デフォルトの名無しさん:04/09/22 11:48:06
習慣的にワンセットでfreeまで書いてしまうよな

966 :デフォルトの名無しさん:04/09/22 11:55:25
いらなくなったらfreeするけど、いらなくなる時点=プログラム終了時
ならexitするだけで済ましちゃうな。楽だし(笑)


967 :デフォルトの名無しさん:04/09/22 11:57:36
age

968 :デフォルトの名無しさん:04/09/22 11:58:55
(笑)

969 :デフォルトの名無しさん:04/09/22 11:59:11
>>966
あーあ。non portableなプログラムを書いてしまったね。

970 :デフォルトの名無しさん:04/09/22 12:00:04
今時ポータブルなプログラムって(笑)

971 :デフォルトの名無しさん:04/09/22 12:00:30
既にそう書かれてしまった過去の遺物、小規模使い捨て、個人用途の
そもそもスタイルを云々することの必要性が皆無なプログラムの場合
好きにしろと言うことだよ。

972 :デフォルトの名無しさん:04/09/22 12:01:11
(笑)

973 :デフォルトの名無しさん:04/09/22 12:09:31
(藁)

974 :デフォルトの名無しさん:04/09/22 12:10:43
(w)

975 :デフォルトの名無しさん:04/09/22 12:12:54
ところで、freeせずにexitするとmallocした領域が戻らない
実装のUNIXにはどういうものがあるか教えてください。

976 :デフォルトの名無しさん:04/09/22 12:19:37
バグ持ちUNIX

977 :デフォルトの名無しさん:04/09/22 12:53:04
そういうのって途中で強制終了したら解放されないんだろうか

978 :デフォルトの名無しさん:04/09/22 12:59:07
リブートしてもリークしたメモリが物理的に焼きついちゃうこともあるらしい

979 :デフォルトの名無しさん:04/09/22 13:06:35
ふーん

980 :デフォルトの名無しさん:04/09/22 13:11:26
今までに書いた最もうんこなコード。
今もどこかで動き続けているに違いない。

void *foo()
{
 static void *buf;
 if(!buf) buf = malloc(...);
 ...
 return buf;
}

981 :デフォルトの名無しさん:04/09/22 13:14:05
なんでstatic

982 :デフォルトの名無しさん:04/09/22 13:38:11
NULLとfreeはセットで

983 :デフォルトの名無しさん:04/09/22 13:48:47
>>985
次スレ乙

984 :デフォルトの名無しさん:04/09/22 14:08:41
【旧態依然】malloc&free総合スレ【温故知新】

985 :デフォルトの名無しさん:04/09/22 14:15:40
次スレ

http://pc5.2ch.net/test/read.cgi/tech/1065535118/

986 :デフォルトの名無しさん:04/09/22 14:22:30
>>965
書くだけか(藁

987 :デフォルトの名無しさん:04/09/22 14:26:41
次は open と close について議論します

988 :デフォルトの名無しさん:04/09/22 15:10:03
>>931
>主に組み込み系エンジニア、またはWin16あたりのクソOSユーザだった人→

Win16でもfreeいらないでしょ。

989 :デフォルトの名無しさん:04/09/22 15:11:41
わざわざfreeしない理由がわからん
OSに頼るのはセーフティネットとして でいいじゃん

990 :デフォルトの名無しさん:04/09/22 15:13:10
やることがないと詰まらない事を考えるようになるんだよ。

991 :デフォルトの名無しさん:04/09/22 15:14:26
>>990
ボケた老人みたいですね

992 :デフォルトの名無しさん:04/09/22 15:16:13
わざわざfreeする理由がわからん

993 :デフォルトの名無しさん:04/09/22 15:20:44
>>991
実際頭の回らなくなってきたロートルがごねてるだけだしな。

994 :デフォルトの名無しさん:04/09/22 15:43:25
>>989
OS に頼らないでプログラムを組むのは(特に Unix の場合)難しいと思うけど。


995 :デフォルトの名無しさん:04/09/22 17:34:06
#define malloc(s) free(malloc(s))

996 :デフォルトの名無しさん:04/09/22 17:39:40
要するにfreeのステータスはチェックしろってこと

997 :デフォルトの名無しさん:04/09/22 17:45:48
unameもそうだけど、
UNIXって意味不明な名前のコマンドだらけで嫌気が差した
いいからメニューから全機能選べるようにしろよ
イミフメコマンド文化なんか続けてるから一向に普及しないんだよ

998 :デフォルトの名無しさん:04/09/22 17:46:37
ほうほうなるほど

999 :デフォルトの名無しさん:04/09/22 17:48:43
誰か本当の次スレ立ててよ・・・

以下テンプレ
-------------------------------------------------------------------
UNIXプログラミング質問すれ Part4
-------------------------------------------------------------------
UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド

前スレ
Part3 http://pc5.2ch.net/test/read.cgi/tech/1085930894/
Part2 http://pc5.2ch.net/test/read.cgi/tech/1055110889/
Part1 http://pc2.2ch.net/tech/kako/992/992057422.html

>>2-20 関連スレ
-------------------------------------------------------------------


1000 :デフォルトの名無しさん:04/09/22 17:50:58
まずは自分の脳味噌をどうにかしろよ馬鹿が

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

205 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)