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

UNIXプログラミング質 ..

427:デフォルトの名無しさん
05/03/07 20:23:57
TRANSITION FROM CURRENT INDUSTRY PRACTICEも読め。

428:デフォルトの名無しさん
05/03/07 20:29:51
128bit化なんてその時になってから泥縄的に考えればいいんだよ。
もし動かなかったらIBMに金出させて力技で修正すればいいだけ。
今困っていない事を今対応するな。これがLinuxのモットーだ。

429:デフォルトの名無しさん
05/03/07 20:33:26
128bit が主流になる頃はおいらは隠居してる.
勝手にやってくれ.

430:デフォルトの名無しさん
05/03/07 20:48:26
というか32→64の経験でスキームは固まっている。

431:デフォルトの名無しさん
05/03/07 20:52:54
ところでIPV5って64bitだったの?

432:デフォルトの名無しさん
05/03/07 20:54:59
型同士の相対的な関係と実際のデータ長っていう
二つの視点で見るとこんなかな。

UNIXは32bit,64bitそれぞれILP32とLP64だけど、
char:short:int:longそれぞれ
ILP32 8:16:32:32 32(pointer)
LP64 8:16:32:64 64(pointer)

ILP32からLP64への移行で変わったのは、
(int,long)と(int,pointer)の相対的関係が変わったことと、
longとpointerの実際のデータ長が変わったということ。

char:short:int:long:long long
ILP128 8:16:128:128:128
LP128 8:16:32:128:128
LLP128 8:16:32:64:128
128bitCPUにおいてはこんな感じのがありえると思うけど、
今UNIXで32bit64bit両方に通用するコードとしてlong=pointerという
仮定の元にコードを書いてしまうともうLP128しかないと思うんだよね。
というかILP32から64bit化においてLP64を採用した時点で
long=pointerという想定を受け入れてるように見える。

ILP128はちょっとありえないね。LP64でせっかくintの実データ長を32で固定した意味がなくなる。
LLP128が1番よさそうに見えるけど、LP64からlongとpointerの相対的関係が異なる。
素人考えだとLP128しかなさそうに見えるけど。

433:デフォルトの名無しさん
05/03/07 21:01:51
つーか128bit時代にもなってLinux使ってたとしたらソフトウェア界の敗北だな。

434:デフォルトの名無しさん
05/03/07 21:02:19
> LP64からlongとpointerの相対的関係が異なる

だから intptr_t, uintptr_t を使えってばさ。
それで問題なし。

435:デフォルトの名無しさん
05/03/07 21:43:35
32bitマシンって1960年代にできて、64bitマシンって1990年頃
だよね。30年くらいかかっている。
同じような指数的ペースで発展する(1年で1bitくらい)として
128bit マシンができるのは、2050年を過ぎたぐらい…

俺は死んでるな。

436:デフォルトの名無しさん
05/03/07 21:46:46
UNIX/Cを潰したいメーカーが96bitマシンとか出して来たりして。

437:デフォルトの名無しさん
05/03/07 22:51:54
なぜbit数が増えるのか
という根源的な疑問は起きないのか？

438:デフォルトの名無しさん
05/03/07 22:59:35
基本的にはストレージのサイズが増えるからという要因が
一番大きいでしょ。(AS/400 みたいに、アドレス空間の
ほとんどを無駄に捨てざるをえないアーキテクチャだと
話は別だが。)
問題は、現在の指数関数的なストレージサイズの増大が、
あと50年続くかどうかと、たとえ続いたとしても、そんなに
使い道があるかどうかだな。
64ビットでも、人類ひとりひとりに、それぞれ2GB以上も
あるというのに。

439:デフォルトの名無しさん
05/03/07 23:02:38
いつの時代もそういう近視眼的な発言をする奴がいたわけで

440:デフォルトの名無しさん
05/03/07 23:05:37
いつの日にか、家庭向けPCで地球シミュレーションが軽く動く日がくるんだよ

441:デフォルトの名無しさん
05/03/07 23:07:41
昔、12bit マシンってのもあったぞ。

442:429
05/03/08 01:57:05
>>439
438 じゃないんだけど, そのころはおいらは隠居してるわけだ.
興味ねぇ.

>>438
> 基本的にはストレージのサイズが増えるからという要因が
> 一番大きいでしょ。

数値計算とかやってると, アドレッシングできる領域がどれだけ増
えても実際の計算速度が上がらないと, メリットは小さい.
やっと 64bit を有効に使える計算速度に達したってのが現実では?

# DB 検索なんかでもそぉだと思うぞ, エンジン作ってる連中にし
# てみれば...

443:デフォルトの名無しさん
05/03/08 01:59:32
>>429
ダウト。
データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。

444:デフォルトの名無しさん
05/03/08 02:36:39
ファイルシステムが2G4G以上をサポートしてる時点で64bit化の恩恵を受けられるわけで。

445:デフォルトの名無しさん
05/03/08 03:12:48
>>444
ブー。mmapが使えないと結構苦しい。

446:445
05/03/08 03:13:48
なんか444へのレスとするのは意味不明だな。ごめん。

447:デフォルトの名無しさん
05/03/08 03:28:32
32bit,64bitそれぞれのシステムでintとlongを使い分けてるけど、
これは一言でいってどういう事情によるものなのかしら？
Linux linux/include/asm/posix_types.h
BSD sys/arch/`uname -m`/include/ansi.h

/*i386*/
#define _BSD_SIZE_T_ unsigned int
#define _BSD_CLOCK_T_ unsigned long
/*amd64*/
#define _BSD_SIZE_T_ unsigned long
#define _BSD_CLOCK_T_ unsigned int

448:デフォルトの名無しさん
05/03/08 03:35:29
Linuxの場合
/*i386*/
typedef unsigned int __kernel_size_t;
typedef long __kernel_clock_t;

/*amd64*/
typedef unsigned long __kernel_size_t;
typedef long __kernel_clock_t;

449:デフォルトの名無しさん
05/03/08 05:16:22
つまりポインタをlong型で扱う奴はバカint型で扱う奴はもっとバカってことでいいですか？

450:429
05/03/08 07:20:28
>>443
> データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。

そぉゆう意味で言ってるんだが...
「やっと」ってゆう言い方が悪かった. すまん.
おれ的には, やっと 10年くらい前からってな感覚だったもんで...

当初からそれなりに, 64bit マシンはメモリバス帯域広いし, マル
チプロセッサ化するために, バスのクロスバ化なんて, ハードウェ
ア的に見た場合, 非効率以外のなにもんでも無いようなことまでやっ
てるところもあるし...
それ以前は, こんなぜいたくはスパコンにしか許されなかったわけ
だから...

451:デフォルトの名無しさん
05/03/08 07:39:51
ｽﾚﾘﾝｸ(tech板)l50

452:デフォルトの名無しさん
05/03/08 09:07:01
printfでtypedefな型を扱えればいいんだが

453:デフォルトの名無しさん
05/03/08 09:12:18
>>448
BSDの方の型は、ユーザー空間にも公開しているものなので、
一度決めると変えない方がいいんじゃないかな。まあユーザー
プログラムが行儀良く書かれていれば、同じサイズの型に
変えても問題ない筈だけど、行儀良く書かれてない場合、
int と long の食い違いが生じると、lint では警告さえる
ケースがありそうな。
あとは、その CPU アーキテクチャの ABI の仕様書に書かれて
いる型名に合わせてるとかもあるかも。

Linux の方はカーネル内部用の型に見えるなので、良くわかんない。

454:デフォルトの名無しさん
05/03/08 09:29:17
>>452
C99 なら一応できるよ。

intptr_t x; なら
#include <inttypes.h>
printf("%" PRIdPTR "\n", x);
とか。

typedef intptr_t MyType;
してるなら同時に
#define PRIdMYTYPE PRIdPTR
もとしておいて、MyType の printf には
PRIdMYTYPE を同様に指定すればいい。

size_t も "z" 修飾子を使ってどうような
ことができる。

455:デフォルトの名無しさん
05/03/08 09:43:57
>>454
> size_t も "z" 修飾子を使ってどうような
> ことができる。

ついでにここも詳しく……

456:デフォルトの名無しさん
05/03/08 10:48:23
128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは
相当長い間必要ないだろ。データバスが128bitなのはGPUじゃ
当たり前になってるんだろうけど。

16bit -> 32bit アドレス空間は6万5千倍。
32bit -> 64bit アドレス空間は42億倍。

このアドレス空間を使い尽くすのっていつ頃？
ヘタしたら人間が絶滅してるかもなｗ

457:デフォルトの名無しさん
05/03/08 10:49:29
>128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは
　　　　　　　　　　　　　　　　　　　↓
128ビットCPU(データバス幅>=アドレスバス幅=128bit)なCPUは

458:デフォルトの名無しさん
05/03/08 11:21:26
>>455
z A following integer conversion corresponds to a size_t or
ssize_t argument. (Linux libc5 has Z with this meaning. Don't
use it.)

#define PRIdSIZE "z"

こういうのあんまり好きじゃないが。

459:デフォルトの名無しさん
05/03/08 11:22:55
>>458
うちのシステムには入ってないや……。

460:デフォルトの名無しさん
05/03/08 11:24:18
あ、標準では定義されてないけど458のように定義すりゃ同じようにできるよ、って
話かな?

461:デフォルトの名無しさん
05/03/09 13:00:27
そゆこと。でも>>458みたいにするんじゃなくて
#define PRIdSIZE "zd"
の方がいい。小文字の「d」の意味がなくなっちゃうから。
#define PRIxSIZE "zx"
とかしたいしね。

462:461
05/03/09 13:46:14
補足。
C99を前提にしていいソフトなら、#defineせずに
"z"を直に書いた方がいいだろうけどね。
#defineする必要があるのは、C99より前の処理系
への移植を考慮する必要があるケースと、あとは
typedef size_t MyType;
#define PRIdMYTYPE "zd"
のように、自分で定義した型に対して printf の
フォーマット文字列を提供したい場合。

463:デフォルトの名無しさん
05/03/09 23:29:27
linuxで、mallocの関数の中身を知りたくて探してるのですが見当たりません。
glibcのソースを探してるのですが。。どこにあるのでしょうか？

464:デフォルトの名無しさん
05/03/09 23:32:00
>>463
ダウンロードした場所にありましたよ

465:463
05/03/09 23:37:42
ダウンロードした場所ですか？
うーん。glibc-xxx/malloc/malloc.cの中とかその周辺とか調べたんですがないんですよ。。

466:デフォルトの名無しさん
05/03/09 23:38:51
入れなきゃ無いわな

467:デフォルトの名無しさん
05/03/09 23:40:22
勝手にソース覗くのはストールマンに失礼ですよ。

468:デフォルトの名無しさん
05/03/09 23:43:22
>>467
アホ発見

469:463
05/03/10 00:03:13
検索したらやっとそれらしいのにヒットした。。
URLﾘﾝｸ(www.gelato.unsw.edu.au)
>BTW, calloc is included in malloc.c.
> You would like to open the file glibc-2.2.4/malloc/malloc.c,
> and then you will be looking for cALLOc. It is calloc function.
そういえばmALLOcみたいな変なのがあったな。。
今ソースがないので明日調べてみます。お騒がせしました。

470:デフォルトの名無しさん
05/03/10 00:38:22
UNIXのソースってなんでこんなに汚いの？

471:デフォルトの名無しさん
05/03/10 00:39:56
お前の顔より綺麗だ

472:デフォルトの名無しさん
05/03/10 16:32:09
なんで俺の顔知ってんの？

473:デフォルトの名無しさん
05/03/10 17:16:57
基本

474:デフォルトの名無しさん
05/03/10 20:35:26
おそらく基本的な質問だとおもいますが
-lpthreadのリンクを下のようにMakefileで記述するとcannot find -lpthreadという
エラーがでてしまいます。

test:main.o sub.o
gcc -o test main.o sub.o -lpthread
main.o:main.c test.h
gcc -c main.c test.h
sub.o:sub.c test.h
gcc -c sub.c test.h

コンソールで一つずつコンパイルしていけば問題はないんですが・・・
よろしくおねがいします

475:デフォルトの名無しさん
05/03/10 21:34:31
-lpthreadをオプションと認識していないみたいですな。
それはともかく、スレ違いです。

476:デフォルトの名無しさん
05/03/10 21:46:46
>>475
Unixプログラミングの場合、スタンダードなIDEがないので、
Makefileやコンパイルオプション指定をする段階から
すでにコーディングの戦いが始まっていると思うのは俺だけですか？

477:デフォルトの名無しさん
05/03/10 21:50:13
ある程度以上の規模なら、IDEを使おうと使うまいと
素敵なビルドの仕組みを作ることは
コード自体を書くことと同じくらい重要でぷ。

478:デフォルトの名無しさん
05/03/10 21:51:24
だからあれほどUNIX捨てろって言ったのに・・・

479:デフォルトの名無しさん
05/03/10 21:53:09
Windowsだとマウスでポチポチやるだけで終わる作業なのにねえ。
UNIXって頭悪すぎ。

480:デフォルトの名無しさん
05/03/10 21:56:15
みえみえの展開に萎え

481:デフォルトの名無しさん
05/03/10 21:58:32
>>474
-lpthread の前に変なコード入ってないか od ででも確認してみたらどうだろう。

482:デフォルトの名無しさん
05/03/10 22:20:31
>>480
みえみえというか、すでに１つのお約束になってますな。
お約束は美しい。

483:474
05/03/10 22:49:23
>>481
もう一回書き直してみましたけど直らないです
あとコンソール直打ちでもcannot findになってしまいました・・・

484:デフォルトの名無しさん
05/03/10 22:54:35
コンソール直打ちでうまくいってたときと、ダメなときの違いはなんなのよ。
libpthread.* がリンカから見えてないんじゃない？

485:デフォルトの名無しさん
05/03/10 23:12:02
たぶん環境変数 LD_LIBRARY_PATH が設定されてたとか、
そういう話じゃないの？でも libpthread が /usr/lib
にない OS ってなんじゃろ？ NetBSD-1.6 とか？

486:デフォルトの名無しさん
05/03/11 00:22:44
>>474
UNIXの種類は何か書いた方がいい。
それ専用の板やスレに行くとモアベター。

487:474
05/03/11 00:29:21
OSはFreeBSD4.11です。専用スレへ行ってきます
スレ汚しすいませんでした

488:474
05/03/11 01:00:05
なんか-lpthreadを-pthreadにしたらリンクできた・・・
ちゃんと動いてるし・・・いいんだろうか・・・(´・ω・｀)

489:デフォルトの名無しさん
05/03/11 01:03:57
>>488
いいです。
-pthreadで、マクロの定義、ライブラリの適切な処理等を行います。

490:474
05/03/11 01:11:28
>>489
どうもありがとうです
前にコンソールでやったのは-pthreadだったかもしれなかったです

491:デフォルトの名無しさん
05/03/11 01:22:00
この謎仕様も悪しきUNIX譲りですか？

492:デフォルトの名無しさん
05/03/11 01:45:01
ここはUNIXプログラミング質問スレですが何か？

493:デフォルトの名無しさん
05/03/11 01:45:43
やっぱWindowsの方がちゃんとしてるな。

494:デフォルトの名無しさん
05/03/11 16:15:29
スレッドってそんなにいいのか？

495:デフォルトの名無しさん
05/03/11 17:07:19
はい。

496:デフォルトの名無しさん
05/03/12 00:40:12
俺よりもいいのか？

497:デフォルトの名無しさん
05/03/12 00:42:55
ごめんなさい。

498:デフォルトの名無しさん
05/03/12 01:27:23
roz 違う… orz

499:デフォルトの名無しさん
05/03/12 07:49:46
・・・

500:デフォルトの名無しさん
05/03/12 14:35:34
>>491
ハァ？プログラミングは「ＵＮＩＸこそが仕様」ですが何か？

501:デフォルトの名無しさん
05/03/12 14:51:54
>>500
-pthreadはUNIX仕様じゃなくて、gccの仕様だろ。

マニュアルに書いてある仕様を謎と呼ぶのは
マニュアルも読めない厨房だけだがな。

502:デフォルトの名無しさん
05/03/12 14:58:09
マニュアルってどこに売ってるんですか？

503:デフォルトの名無しさん
05/03/12 15:34:57
groff出力のテキストまたはポストスクリプトが、
アマゾン川流域で、約1000ペソ。

504:デフォルトの名無しさん
05/03/12 16:05:24
>>503
日本で買えませんかねぇ･･･

505:デフォルトの名無しさん
05/03/12 18:31:50
もうＰＯＳＩＸだのＡＮＳＩだのめんどくさいよ
ぜんぶＭＳのWindowsにあわせればＯＫだよ。

506:デフォルトの名無しさん
05/03/12 20:59:20
WindowsのmessageとPOSIX Message Queueってどう違うの？

507:デフォルトの名無しさん
05/03/12 22:46:22
商用UNIXだったらしっかりしてるんだけどね。

508:デフォルトの名無しさん
05/03/14 01:07:10
UNIXやWindowsで動く自作言語を作っているのですが、
UNIXの例外処理はどんなロジックを使えばよいでしょうか？
Windowsの場合はSEHという機構を使ってます。
Javaでいうfinallyやcatch辺りの処理の話です。

509:デフォルトの名無しさん
05/03/14 01:21:57
>>505
ＭＳのWindows（ゲイツ）は、ＰＯＳＩＸだのＡＮＳＩにあわせるよう努力してくれるが、
逆の努力は誰もしてくれない。

Unixに腐敗臭が漂うのも無理はない。19世紀の老大国を見る思いだ。

510:デフォルトの名無しさん
05/03/14 01:54:34
ようするにUnixは何をやるにしてもダメっていうことね。

511:デフォルトの名無しさん
05/03/14 01:57:38
そうだね。UNIXも使えない人な何をやってもダメだね。

512:デフォルトの名無しさん
05/03/14 01:58:46
皮肉でしか返せないんだね

513:デフォルトの名無しさん
05/03/14 02:04:42
>>508

実装言語による。
C++で書くなら、C++標準の例外処理処理機構を使えばいいんじゃない？
Cで書くなら、自分で明示的に制御するしかない。

514:デフォルトの名無しさん
05/03/14 02:06:48
WindowsがやってるPOSIXに合わせようとする努力って
なんの話？ SFUのこと言ってるのかな？
だったらUNIX上での似たようなものとしてはWineとか
Monoがあるよ。
というわけで、逆の努力もしてるってことで終了。

515:デフォルトの名無しさん
05/03/14 02:38:16
コンパイラをANSIに対応させるのは当たり前だし
WindowsNTにPOSIXサブシステムがあったのは「POSIXに準拠してないと導入しない」と
アメリカの政府機関が言い出したからなんだけどな

516:デフォルトの名無しさん
05/03/14 03:01:02
>>515
NT系Windowsの POSIXサブシステムはそういう話だね。
はっきり言ってあれは全く使いものにならんかった。
FIPS規格に通ることだけが目的で、実用性ゼロ。

でもSFUの方は結構ましだと思うけど。
もちろん、ソースレベルの限定的な互換性しかないから、
バイナリ互換性を提供してくれるWineやMonoには劣るけど。

517:デフォルトの名無しさん
05/03/14 04:09:45
Unixer達はなんだかんだ言いながらもWindowsのアプリを動かしたくてたまらないちうことやね。
憧れちゃいますかそうですか。

518:デフォルトの名無しさん
05/03/14 04:21:02
別に好きで使いたいわけじゃないんだけど、上司や客が
WordやExcel形式で文書を送ってくるので仕方ないっすよ。
という俺はVMwareのクライアントOSとしてWindowsを動かす派。
自分で一から書く文書には、もちろんそんなの使わないけどネ。

519:デフォルトの名無しさん
05/03/14 04:27:17
結論。
Unixerはいらん苦労が好き。

520:デフォルトの名無しさん
05/03/14 04:39:38
>>518
今ならOpenOffice使うって手もあるけどね。
互換性はまだまだ低いけど。

521:デフォルトの名無しさん
05/03/14 04:57:31
UNIXは昔からtelnet（というかteraterm）経由ですが何か？
それで問題起きたことないなあ。
つーかteratermなかったらUNIXなんてとっくに死滅してたね。
おまえらもっとteratermの作者に感謝すべきだと思いませんか？

つーかWindows上からteratermの快適さに比べたらX？ナニソレって感じ。
あんなのインスコしてもディスクの無駄。
どーせemacs動けばいいしね。

522:デフォルトの名無しさん
05/03/14 04:58:27
おっと誤爆した。

523:デフォルトの名無しさん
05/03/14 08:56:03
teratermを理由もなしに誉めるようじゃ……

524:デフォルトの名無しさん
05/03/14 09:23:07
telnet上でファイルをやり取りできたらすべての作業がtelnetでやるんだけどできる？

525:デフォルトの名無しさん
05/03/14 10:07:56
できるね。

526:デフォルトの名無しさん
05/03/14 10:18:16
>>525
Unixユーザ特有の思考停止だな。

ターミナル経由でなければできないことは、
想定しないように脳内で排除フィルタが発動する。

527:デフォルトの名無しさん
05/03/14 10:31:55
>>526
確かに面倒ではあるが、uuencodeして標準出力に出力、
telnet端末ソフトにログ機能などがあるだろうからそれを利用して端末側でuudecode。
自分の知識のなさを他人の思考停止に置き換えないように。

528:527
05/03/14 10:34:08
訂正。
s/telnet端末ソフト/telnet端末ソフト側/
Windows標準のtelnetでも(windowsの機能を利用して)copy&pasteくらいできるだろ。

529:デフォルトの名無しさん
05/03/14 11:04:48
関係ない話ししはよそでおねがいします

530:デフォルトの名無しさん
05/03/14 11:10:49
結論から言うと、できないことだらけなのだが、

Unix信者には、「それはそもそも、XであってUnixではない。」
と嘯きつつ逃亡する退路が確保されているので、
Unix信者を追及するのは時間の無駄。

531:デフォルトの名無しさん
05/03/14 11:16:01
時間の無駄だと言いながら、自分が最後に何か言わないと気がすまないのかね。

532:デフォルトの名無しさん
05/03/14 14:35:54
ほりえもんもUNIXにビジネスチャンスは無いってさ

533:デフォルトの名無しさん
05/03/14 14:47:26
おまえらこれを読んでから言え
URLﾘﾝｸ(www.amazon.co.jp)

534:デフォルトの名無しさん
05/03/14 14:53:55
UNIXの歴史を物語りみたいに仕立て上げたのって嫌い。文系厨みたい。
ただの実装史と割り切って書かれてる、スティーブンスの本は好き。

535:デフォルトの名無しさん
05/03/14 15:29:54
がたりり?

536:デフォルトの名無しさん
05/03/14 15:58:08
teraterm使ってる時点で既にUnix信者じゃないと思うけどね。
そういう俺は当然ktermですよ。mltermでも可。(w

537:デフォルトの名無しさん
05/03/14 16:01:06
むつかしくてわらえない

538:デフォルトの名無しさん
05/03/14 18:23:40
そもそもUNIXでプログラミングする事なんてあるの？
teratermみたいにUNIX使うためのWindowsプログラミングでもしてた方がいいんじゃない？

539:デフォルトの名無しさん
05/03/14 18:28:10
時間の無駄だと言いながら、自分が最後に何か言わないと気がすまないのかね。

540:デフォルトの名無しさん
05/03/14 19:03:06
>>538
そりゃあるよ。だいたい世の中の7割のWebサイトは
(Linuxを含む)UNIX系OSで動いているんだしさ。
ソフトウェア開発作業を必要とする大規模なサイト
になるほどUNIX系OSのシェアは上がるし。
googleだってamazonだって、Linuxとかそういう
UNIX系OSで動いてるのは知らない?

541:デフォルトの名無しさん
05/03/14 19:39:43
てゆうか2chもUNIX系OSで動いているわけだが。

542:デフォルトの名無しさん
05/03/14 19:45:32
てゆうか2chもWindows系OSで動かせばいいんだ｡

543:デフォルトの名無しさん
05/03/14 20:02:35
実際問題として、ライセンスにかかる価格の問題だけ
考えても Windows にすることはありえないけどね。
Windows XP だとクライアント数10までというライセンス
制限にひっかかるから、Windows 2003 Server が必要。
これで 1台あたり10万円×台数分の金がかかる。
これに対し、今みたいに FreeBSD や Linux を使ってれば
ライセンス台はタダ。
Windows にするだけで性能が向上して、台数が1/10で済む
とかいう効果があるのならともかく、そんなことも全然ない
わけだし。

544:デフォルトの名無しさん
05/03/14 20:19:49
宗教的にUNIXだよもん

545:デフォルトの名無しさん
05/03/14 21:34:14
Windowsのほうが得意なことはWindowsでやればいいものを、
わざわざkterm上でやって「難しいなあ」とか喜んでる奴は末期症状

546:デフォルトの名無しさん
05/03/14 21:34:25
>>533
そのページを読めばいいんですね?

547:デフォルトの名無しさん
05/03/14 21:39:29
別に難しいことないけど。
てゆうかWindowsで好みの設定にするのは俺には難しい。(w
UNIXだとcp .??*だけですむので俺には簡単。

もちろん、君にとっては逆だろう。いいじゃん好きずきなんだし。

548:デフォルトの名無しさん
05/03/14 21:44:18
つーかWindowsはデフォルトで快適だからなあ。

549:デフォルトの名無しさん
05/03/14 21:44:51
関係ない話しししはよそでおねがいします

550:デフォルトの名無しさん
05/03/14 21:54:35
かたいこと言うな

551:デフォルトの名無しさん
05/03/14 22:00:48
UNIXはいまだに基本がC言語なのがいかんと思う。
その上信頼性もクソもないshで書きなぐられたシステムなんか保守したくないだろ？

552:デフォルトの名無しさん
05/03/14 22:03:31
GNUﾏﾝｾｰ

553:デフォルトの名無しさん
05/03/14 22:04:15
そういや某国はUNIXに進出しようとして失敗したな。

554:デフォルトの名無しさん
05/03/14 22:33:54
>>551
シェルスクリプトは滅多にエラーにならないからエラー処理は
必要なくてとても信頼できるらしいです
うちのUNIX暦20年の課長(40)が言ってました
エラーになっても気付いてないだけじゃないんですか、と言おうと
しましたがやめておきました

555:デフォルトの名無しさん
05/03/14 22:44:22
何について信頼できないとか言ってるのかよく
分からないんだが、シェルスクリプトだって
エラー処理ぐらいできるし、俺はやってるよ。

556:デフォルトの名無しさん
05/03/14 22:51:19
たぶんそれぞれのエラー処理の意味がちがってるとおもう

557:デフォルトの名無しさん
05/03/14 23:21:09
>>508
コンパイラですかインタプリタですか?
その自作言語の実行スタックはどういう構成でしょう?

schemeのインタプリタ、コンパイラは参考になると思います。

558:デフォルトの名無しさん
05/03/15 00:05:48
すみません、質問させてください。
こういうプログラムを書いたのですが、
#include <iostream>

main()
{
cout << "hello";
}

gcc test.cppと書いてコンパイルすると、

/tmp/ccHDOsZp.o(.text+0x19): In function `main':
: undefined reference to `std::cout'
/tmp/ccHDOsZp.o(.text+0x1e): In function `main':
: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std
::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits
<char> >&, char const*)'
/tmp/ccHDOsZp.o(.text+0x4a): In function `__static_initialization_and_destructio
n_0(int, int)':
: undefined reference to `std::ios_base::Init::Init[in-charge]()'
/tmp/ccHDOsZp.o(.text+0x79): In function `__tcf_0':
: undefined reference to `std::ios_base::Init::~Init [in-charge]()'
/tmp/ccHDOsZp.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld はステータス 1 で終了しました

というエラーがでるのですが、C++のコンパイルの仕方が間違っているのでしょうか。

559:デフォルトの名無しさん
05/03/15 00:08:52
>>558
いいえ

560:デフォルトの名無しさん
05/03/15 00:12:01
g++もしくは-lstdc++

561:558
05/03/15 00:12:54
ごめんなさい、std::を忘れてました。

>>559
対処法はあるのでしょうか・・・。よかったら教えてください。

562:デフォルトの名無しさん
05/03/15 00:22:55
スレ違い。
gccスレで聞け。

563:デフォルトの名無しさん
05/03/15 00:39:38
>>559は嘘。
コンパイルのしかたが間違っとる。

>>560が書いているように、gcc じゃなくて g++ か
あるいは c++ コマンドを指定する必要がある。

564:デフォルトの名無しさん
05/03/15 01:11:53
ここは盥回しスレですか。

565:デフォルトの名無しさん
05/03/15 09:44:25
↑
盥・・・すごい字があるんだな、知らなかったﾖ

566:デフォルトの名無しさん
05/03/15 10:03:09
もう10

567:デフォルトの名無しさん
05/03/15 14:47:14
>>558
ソースコードが間違ってます。

冒頭で、

using namespace std;

とするか、std::coutとするのが今ん流儀です。

それ以外は処理系依存の動作。

568:デフォルトの名無しさん
05/03/15 15:07:05
C++の名前空間がうんこなのは仕様です。

569:デフォルトの名無しさん
05/03/15 15:22:24
>>577
それは既に>>561で本人が気づいてる

570:デフォルトの名無しさん
05/03/15 15:39:47
>>577
やーいばーか

571:デフォルトの名無しさん
05/03/15 15:41:58
>>577
とんだ災難だとは思うがよろしく頼む。

572:567
05/03/15 16:15:53
俺が>>577に>>567と同じ内容を書いて大団円。

573:デフォルトの名無しさん
05/03/15 20:56:32
>>572
お前おもしろいな

574:デフォルトの名無しさん
05/03/16 01:00:29
574

575:デフォルトの名無しさん
05/03/16 01:01:00
575

576:デフォルトの名無しさん
05/03/16 01:01:41
576

577:デフォルトの名無しさん
05/03/16 01:03:40

578:デフォルトの名無しさん
05/03/16 01:08:34
>>577
ﾈﾀもないのに書くなYO!

579:567
05/03/16 03:04:40
>>587
ソースコードが間違ってます。

冒頭で、

using namespace std;

とするか、std::coutとするのが今ん流儀です。

それ以外は処理系依存の動作。

って書こうと思っていたのにッ…orz

580:デフォルトの名無しさん
05/03/16 03:08:27
もうこのくらいでやめとこうや。
な？

581:デフォルトの名無しさん
05/03/16 04:20:47
｜

582:デフォルトの名無しさん
05/03/16 11:16:00
age

583:デフォルトの名無しさん
05/03/17 16:47:56
gdb でデバッグするために
gcc で -g をつけてデバッグ情報つきの
オブジェクトファイルを作ってから
リンクしました．

ところができた実行ファイルを gdb しても
デバッグできません．
たとえば list しても

No symbol table is loaded. Use the "file" command.

とでます．

-g をつけるとたしかに .o ファイルはサイズが増えていますが，
最終的にリンクすると，できた実行ファイルは -g を
つけようとつけまいとなぜか変わらないんです．

なぜでしょうか？

584:デフォルトの名無しさん
05/03/17 16:53:20
リンクするときに-gをつけてないとか。

585:583
05/03/17 16:58:50
>>584
リンクするときに -g つけてもつけなくても結果は同じです

586:デフォルトの名無しさん
05/03/17 17:10:29
リンクするときに-sをつけているとか。

587:583
05/03/17 17:21:53
>>586
たしかにリンクに -s がついていて
これをはずすとデバッグできました
他人が書いたソースなもんで

man 見たところ -s に対する説明がありませんね
-S はありますが．
これはなんでしょうか？

588:デフォルトの名無しさん
05/03/17 17:34:29
少しは上の方を見ろよ。

589:429
05/03/17 20:46:23
>>587
> man 見たところ -s に対する説明がありませんね
% man ld
<snip>
-s
--strip-all
Omit all symbol information from the output file.

-S
--strip-debug
Omit debugger symbol information (but not all symbols) from the
output file.

<snip>
って, 書いてあるが...

590:デフォルトの名無しさん
05/03/17 20:48:22
わかりにくいなあ
なあ！

591:デフォルトの名無しさん
05/03/17 21:14:43
Solaris のコンパイラ (Forte, Sun ONE Stuido) のマニュアルには
ちゃんと書いてあるよ。

　　　　　-s　　　Removes　all symbolic debugging information from the
　　　　　　　　　　output　object file. This option is passed to ld(1).
　　　　　　　　　　This option cannot be specified with -g.

gcc 場合、マニュアルには確かにないねえ。
しかし gcc の info を見ると実は書いてある。
GNU 系の場合、これはありがち…
だから GNU は(ry

592:デフォルトの名無しさん
05/03/17 21:19:38
>>591
> gcc 場合、マニュアルには確かにないねえ。
> GNU 系の場合、これはありがち…

おれは, 一時期, gcc だと obsolete になったのかと思って,
-Wl で ld に渡してたぞ.

だから GNU は(ry

593:デフォルトの名無しさん
05/03/17 21:23:07
>>591-592

594:デフォルトの名無しさん
05/03/17 22:16:12
1から100までの自然数を素因数に分解して出力しなさい

誰かＣ言語でプログラム書いてもらえませんか？

595:デフォルトの名無しさん
05/03/17 22:18:19
>>594
俺様に命令するな！！！

596:デフォルトの名無しさん
05/03/17 22:19:29
たのみますｍ(＿＿)ｍ

597:デフォルトの名無しさん
05/03/17 22:25:36
>>594
最高速なアルゴリムを示そう。

int main()
{
fputs("2: 2\n"
"3: 3\n"
"4: 2, 2\n"
... 自分で埋めろ
, stdout);
return 0;
}

(1も素因数分解できるんだっけ？素因数ってもう忘れた)

598:デフォルトの名無しさん
05/03/17 22:34:54
うちの gcc の man page には書いてあるんだが…

> -s Remove all symbol table and relocation information from the exe-
> cutable.

gcc-3.3.3 です。

599:デフォルトの名無しさん
05/03/17 22:39:41
>>597
それって stdio のせいで遅くね?

600:デフォルトの名無しさん
05/03/17 23:00:46
writeはエラー処理がめんどくさい。
全部書けなかった時とか、EINTRとか。

601:デフォルトの名無しさん
05/03/17 23:09:51
#include <stdlib.h>
#include <stdio.h>
#define BUF_SIZE 256
int main(void)
{
int i;
char buf[BUF_SIZE];

for (i = 1; i <= 100; i++) {
snprintf(buf, BUF_SIZE, "factor %d", i);
system(buf);
}

return 0;
}

602:デフォルトの名無しさん
05/03/17 23:14:47
>>598
うちはgcc-2.95.3ですた。
gcc-3 になって心を入れ換えた?

603:デフォルトの名無しさん
05/03/18 00:16:34
>>600
fputs() でも一緒だと思うが...。

604:デフォルトの名無しさん
05/03/18 01:20:27
うんにゃ。
少なくとも全部書けなかった場合については、
fputs() は、内部で再試行してくれます。

むか～しの SVR4 が、これをやってくれなくて欝だった
ような覚えがあるが。

605:デフォルトの名無しさん
05/03/18 02:55:44
>>604
初期のSVR4はsignalの振る舞いが、
defaultではBSD風じゃなくて、SVR3風だった。すぐに変ったけど。
だからsystem call中に、signalを受けると、エラーで失敗した。
ライブラリもsystem callに再入せず。(BSDセマンティクスだとする)

606:じじー
05/03/18 04:17:10
>>605
> defaultではBSD風じゃなくて、SVR3風だった。すぐに変ったけど。
これは、今でもそうじゃない？
signal(3) はデフォルトでは SA_RESTART しない筈。

で、ここで書いた write(2) の再試行ってのはシステムコール
リスタートの話じゃないの。それならまだ許せる。
初期の SVR4 では、write(2) が第3引数よりも少ない正の値を
返した場合 (つまり partial write の場合)、残りを単に捨て
ちゃってたような気が… つまり完全にバグ。

607:じじー
05/03/18 04:18:58
補足。
partial write の残りを捨ててたのは stdio ライブラリね。

608:デフォルトの名無しさん
05/03/19 12:45:25
>> 592 さん
gcc の man にはこう書いてありますが。

The information in this man page is an extract from the
full documentation of the GNU C compiler, and is limited
to the meaning of the options.

This man page is not kept up to date except when volun
teers want to maintain it. If you find a discrepancy
between the man page and the software, please check the
Info file, which is the authoritative documentation.

609:デフォルトの名無しさん
05/03/20 00:43:02
>>601
え　れ　が　ん　と（ﾆｺﾘ

610:デフォルトの名無しさん
05/03/20 02:47:45
標準C言語スレで聞いたら怒られたのでこちらで質問させてください。
mmapの動作に関する質問です。

//#include *は省略
#define SIZE 536870912
int main() {
void *map;
int fd = open("tmp_file", O_RDWR);
size_t size = (SIZE / getpagesize() + 1) * getpagesize();

map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_FIXED, fd, 0);
munmap(map, SIZE);

return 0;
}

というプログラムを動かすとバスエラーになってしまいます。
また、変数sizeを使わずにSIZEを使うとセグメントエラーになります。
mmapはファイルをメモリに全部読み込まずに必要な分だけキャッシュする
とmanに書いてあるように読めたのですが、間違いでしょうか。
環境はFreeBSD 5.3R, gcc 3.4.2です。メモリは512MBです。

611:デフォルトの名無しさん
05/03/20 03:15:56
商用UNIXだったら分かるんだけどなー。

612:デフォルトの名無しさん
05/03/20 03:45:13
>>610
mmapに渡してるsizeとmunmapに渡してるSIZEは同じなのか？
つーかちゃんとエラーチェックしろよ。
とりあえずstraceでもしてみれば？

613:デフォルトの名無しさん
05/03/20 04:06:01
>>610
> #define SIZE 536870912

これって二進で100000000000000000000000000000、30bitじゃん。

幾らなんでもでかいだろ。
そのカーネルはユーザ空間どれくらいとれるの?
詳しいところ調べるの無理だったら、UNIX板のFreeBSD質問スレが良いかも。

614:デフォルトの名無しさん
05/03/20 06:18:36
問題は>>613や>>612が指摘している点もあるが、それ以前に、
第一引数が 0 なのに MAP_FIXED を指定している点もある。
0番値から連続で512MBも置き換えたら、現在実行している
プログラムからなにから全部置き換えになるから、そりゃ
コアダンプもするだろ。

それから、flags には、必ず MAP_PRIVATE か MAP_SHARED
のどらかか片方は指定するようにしろ。

あと、>>612 が言うように、システムコールがエラーで返って
ないか調べて、エラーだったら perror() なりerr() する習慣
をつけろ。基本中の基本。

これだけ短いプログラムに、なんでこんなにたくさんバグを
入れられるのかが謎だ。もっと人の書いたちゃんとしたプログラム
を読んで真似する習慣をつけるべき。

615:デフォルトの名無しさん
05/03/20 06:57:39
どっかのクズサンプルをつかまされたのだろうきっと

616:デフォルトの名無しさん
05/03/20 10:47:37
バグと言っていいかどうか微妙だなｗ

617:610
05/03/20 11:46:33
>>612
あ、SIZEはtypoです。実際は両方ともsizeを指定してます。
あと、エラーチェックもperrorを実際は入れてます。
長くなると迷惑かと思って省略してしまいました、ごめんなさい。

>>613
その辺をうまくよきに計らってくれるのがmmapだと認識してたのですが・・・
間違いでしたか。

>>614
flagsにMAP_PRIVATEを入れたら行けました。
何か勘違いしてるみたいなのでもちっとじっくりmanを読んでみます。
ありがとうございました。

618:デフォルトの名無しさん
05/03/20 12:35:43
仮想メモリ空間が足りないのに良きに計らうもクソも無いだろ

619:デフォルトの名無しさん
05/03/20 13:37:38
>>613
>>610 ではないだが
> 30bitじゃん。
> 幾らなんでもでかいだろ。
なんで?
ふつうに,
mmap(0, 1024L*1024L*1024L, ...)
って, 使えてるが.
FreeBSD でも Solaris でも IRIX でも...
CPU アーキテクチャにもよるだろうけど, 32bit あれば
2G のユーザ空間確保できるのが普通じゃねぇの.

620:デフォルトの名無しさん
05/03/20 13:42:05
>>619
> CPU アーキテクチャにもよるだろうけど, 32bit あれば
> 2G のユーザ空間確保できるのが普通じゃねぇの.

なことはない。

621:デフォルトの名無しさん
05/03/20 13:47:05
>>620
> なことはない。
だから, なぜだか教えてほしいって言ってるじゃん.
backing store に指定容量以上ののファイルとか,
十分な量の swap 持ってきてもだめなの?

622:デフォルトの名無しさん
05/03/20 13:55:44
よくあるケースは、
・32bitアドレス空間を、半分カーネル空間
・ユーザ空間の半分をテキスト領域
・残りをスタック領域とデータ領域
・sparseであることを仮定したmmap設計
などなど

x86はセグメントありますから、32bit全部データ領域は可能。

623:デフォルトの名無しさん
05/03/20 14:02:45
UNIX userはやたらとalphabetで書きたがるね。

624:デフォルトの名無しさん
05/03/20 14:04:35
それが UNIXer quality

625:621
05/03/20 14:08:40
>>622
> よくあるケースは、
> ・32bitアドレス空間を、半分カーネル空間
mips あたりだと CPU が, そうゆう設計ですよね.

> ・ユーザ空間の半分をテキスト領域
こんなのって本当にある? バイナリの仕様次第か?
FreeBSD とか, 昔の SunOS-4 なんかだと
2^32/2 - text+maxdsiz+maxssiz が,
mmap で使用可能な空間ですよね?

> ・sparseであることを仮定したmmap設計
> などなど
64bit ならまだしも 32bit でやるかなぁ???

> x86はセグメントありますから、32bit全部データ領域は可能。
トロくなりませんか, OS が?

626:621
05/03/20 14:11:15
> mmap で使用可能な空間ですよね?
ごめんなさい,
mmap(NULL, ..., /*MAP_FIXED ではない*/)
の話.

627:デフォルトの名無しさん
05/03/20 15:58:01
そもそもmmap自体がポータブルじゃないので
良きに計らえとか言ってると火傷します

628:デフォルトの名無しさん
05/03/20 16:38:42
Windows使うのが安全。

629:デフォルトの名無しさん
05/03/20 17:10:23
同意。
わざわざ面倒なことする必要もない。

630:デフォルトの名無しさん
05/03/20 17:13:25
FreeBSD/i386 を含め、386BSD から派生した OS は
i386 上だと、VM_MAXUSER_ADDRESS=3G くらいだから
512MB くらいなら mmap できることが多いよ。
KVM を広げるようにカーネルを config してたり、
他にいろいろ mmap してたりすると別だし、
0番値から MAP_FIXED で mmap してたらまずいけど。
>>617 は MAP_PRIVATE を入れただけじゃなくて、
MAP_FIXED は取り除いたんじゃないかな。

m68k 用 NetBSD は、カーネルとユーザ空間に別の
仮想空間を使っているので、ユーザ空間だけで 4GB
使えたり。

ユーザー空間が 4GB/2=2GB って OS は多いけど、
text に 2GB/2=1GB も割り当てるなんてもったいない
ことしてる OS はないと思う。text は、実行ファイル
に含まれている分しか確保されない。むしろ、
ヒープと stack の中間に shared library 用の mmap
領域があったりすることが問題。

631:デフォルトの名無しさん
05/03/20 17:13:47
>>627
mmap は、いまや POSIX.1:2004 に含まれているので、
そこそこポータブルですが、なにか？
Linux や *BSD など、POSIX.1:2004 をフル実装して
ない OS でも、mmap に関しては、ほぼ POSIX.1:2004
の仕様を満たしているよ。もっとも、定義されている
のは、各 OS の最大公約数程度の機能だけど。

632:デフォルトの名無しさん
05/03/20 17:15:24
>>628
Windows のメモリマップドファイルって、ローカル
ファイルシステムはマップできるけど、リモートに
ある奴は駄目という不便な仕様だった記憶があるけど
今では直ったの？
UNIX の場合、当然そんな制限はありません。

633:デフォルトの名無しさん
05/03/20 17:28:28
>>631
POSIXに含まれている＝ポータブルではない。
「そこそこポータブル」って何だよ。

> mmap に関しては、ほぼ POSIX.1:2004 の仕様を満たしているよ。
本当に？A LinuxとB LinuxとC LinuxとD LinuxとFreeBSDで使えても
ポータブルとは言わないよ？

634:デフォルトの名無しさん
05/03/20 17:32:10
わははは！
ペイントハウスで思いのままだ！

635:デフォルトの名無しさん
05/03/20 17:37:57
>>633
> 本当に？A LinuxとB LinuxとC LinuxとD LinuxとFreeBSDで使えても
> ポータブルとは言わないよ？

で、君は使えない処理系の一つでも挙げればいいんだけど、自分は何も知らないけど煽ってるだけと言うことでいいの ?

636:デフォルトの名無しさん
05/03/20 17:46:23
>>633
POSIX.1:2004に書いてある仕様なら、Solaris, IRIX, Tru64, HP-UX,
AIX は使ってないので知らんが。これで現在でもメンテされている
商用UNIXはほぼ全部。ちなみにこの程度の範囲の仕様なら、いにしえ
の SunOS4 でも通用する。
mmap はシステムコールなので、別に A Linux, B Linux なんて
言わなくても全部の Linux で同じ動作だし、あの範囲の仕様な
ら、実際に Linux でも通用する。FreeBSD に限らず、全ての
4.4BSD 派生 OS でも通用する。

最初にまともな実装が登場した SunOS4 の時代ならともかく、
あれから 15年も経った今でもポータブルでないっていうのは
時代遅れだと思う。

637:636
05/03/20 17:48:22
編集してたら文章が欠けた…

> POSIX.1:2004に書いてある仕様なら、Solaris, IRIX, Tru64, HP-UX,
> AIX は使ってないので知らんが。

POSIX.1:2004に書いてある仕様なら、Solaris, IRIX, Tru64, HP-UX は
少なくとも満たしている。AIX は使ってないので知らんが。

638:デフォルトの名無しさん
05/03/20 18:21:48
611の言ったとおり、やっぱり商用UNIXじゃないとな。

639:デフォルトの名無しさん
05/03/20 18:32:28
>>638
だったらAIX以外ならOKよ。
AIXは、mmapは大丈夫かもしれんが、そもそもOSが変態だから
やめた方がいいかもしれん。

640:デフォルトの名無しさん
05/03/20 18:34:24
> A LinuxとB LinuxとC LinuxとD Linux
ﾜﾛﾀ

641:デフォルトの名無しさん
05/03/20 18:45:28
ここで質問すると、かならず無駄に互換性の話まで拡大するのな。
大抵の質問者が環境書かないからだと思うけど、
今回は環境かいても無駄だった。

642:デフォルトの名無しさん
05/03/20 18:55:20
で、件のFreeBSDでは動くのかというと、正確な所は誰も知らないと言う・・

643:デフォルトの名無しさん
05/03/20 18:58:03
POSIX.1:2004 の範囲ならFreeBSDでも動くよ？
元々の610のプログラムはバグバグなので、どのOSでも動かん。

644:デフォルトの名無しさん
05/03/20 19:13:13
たぶんWindowsなら動くんだよ。

645:デフォルトの名無しさん
05/03/21 02:25:57
特定のUNIXモドキ、しかも商用UNIXじゃないんだから
正確なところが分からなくても仕方ないと思う

646:デフォルトの名無しさん
05/03/21 03:22:59
basename()が引数の指す先を変更することってあるんですか？

647:デフォルトの名無しさん
2005/03/21 03:49:09(月)
>>610
どこの本やサンプルを見たらあんなコードになるのか興味深い
駆逐したいのでどこを参考にしたのか教えて欲しい。

648:デフォルトの名無しさん
05/03/21 09:16:03
>>646
URLﾘﾝｸ(www.linux.or.jp)
＞path の内容を変更することがある。
だそうだ。

649:デフォルトの名無しさん
05/03/21 09:43:42
ちゃんと嫁

650:デフォルトの名無しさん
05/03/21 11:50:10
>>648
どちらかに決まってないんじゃ、呼び出した後free()すべきか
どうかどうやって決めればいいんでしょう？

651:デフォルトの名無しさん
05/03/21 12:21:58
free() ?
自分が確保したものは自分で free() するのが基本。
strdup() みたいに、ライブラリ内で確保するやつもいるけど、そういうやつはマニュアルに書いてある。

652:デフォルトの名無しさん
05/03/21 12:35:46
>>650
> dirname および basename は、静的に割り当てられたメモリへのポインタを
> 返すことがあり、これらの領域は後の関数呼び出しで上書きされるかもしれない。
…の部分に対する疑問？

それなら、

char * path = "foo/bar";
char * path_dup = strdup(path_dup);

char * path_dir = dirname(path_dup);

して、

free(path_dup);

すればいいだけだと思うが。

path_dup = dirname(path_dup);

みたいにすると、path_dup が strdup で確保したメモリじゃない可能性があるから、
free() するべきかどうか分からなくなるがね。

次ページ