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

1 名前：名無し募集中。。。 [05/01/15 02:18:37] UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド 前スレ Part4 pc5.2ch.net/test/read.cgi/tech/1095843584/ Part3 pc5.2ch.net/test/read.cgi/tech/1085930894/ Part2 pc5.2ch.net/test/read.cgi/tech/1055110889/ Part1 pc2.2ch.net/tech/kako/992/992057422.html Part3のミラー makimo.to/2ch/pc5_tech/1085/1085930894.html Part2のミラー makimo.to/2ch/pc5_tech/1055/1055110889.html 関連スレ Cygwin使っている人いますか？ その13 (UNIX板) pc5.2ch.net/test/read.cgi/unix/1099157755/ Cygwin使っている人いますか？ 3 (Windows板) pc5.2ch.net/test/read.cgi/win/1090131123/ 関連板 pc5.2ch.net/unix/ pc5.2ch.net/linux/ 357 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:18:15 ] >>351 だから何ですか？ 一般論を聞きたいのではなく、 入れたい場合が出てきたということです。 >>352 詳しく教えてください。 >>354 リンカでどうやって繋ぐのでしょうか？ >>356 初期済みのデータが初期化済みデータのことならその通りです。 358 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:31:03 ] そういえばX Windowってリソース管理どうなってんの？ アイコンとかって外部ファイル？ もしかしていちいちパス指定で取ってきてる？ パス管理複雑にならない？ 359 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:31:28 ] Cで初期化された大域変数をリンクするのと同じということでは？ ELFの話はLinkers & Loadersていう本にそれなりに載ってる気がする。 360 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:31:52 ] X or X Window System 361 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:38:33 ] つまんねー揚げ足すんなよ おまえ、つまんねー奴って言われるだろ 362 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:39:22 ] >>359 そういうことでしたら 既存の実行ファイルに対して追加したいので リンカを使う方法は無理です。 363 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:40:35 ] >>357 >だから何ですか？ 漏れは351じゃないけど、別に多少関連した雑談や世間話くらいしても良いと思うんだけど・・・ 質問と回答以外はスレ違い、っていう立場もあるのかもしれないけど。 >リンカでどうやって繋ぐのでしょうか？ テキトーなバイナリなりXMLなり文字列なりをソースとして、 const unsigned char appResourceHoge[] = { 0x11, 0x22, .............. }; みたいなソースファイルを出力するスクリプトなんかを使う。 Xのコードとか書いたことがあればイメージできると思う。 実行ファイルに細工したい（ソース無しでリソースだけ変更したい）って用途には向かない。 なんだから偉そうな質問者様に対してこんな返事しかできなくてごめんね。 364 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:40:43 ] なあ、俺もUNIXでトロイ作りたいんだけど、 実行ファイルのフォーマット教えてくれよ 365 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:41:29 ] >>362 ん？既存の実行ファイルを弄らないなら埋め込んでも意味ないだろ？ 埋め込んだ上でそれを使うように修正しないと 366 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:41:56 ] >>363 うわ、そんなことできるならはじめからやってるだよ 367 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:42:53 ] どうやらここのUNIX使い様はリソースって概念がわからんらしい 368 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:43:23 ] >>365 Windowsのリソースのように、バイナリに埋め込まれていてかつ後から 編集できるデータ格納方法は無いだろうか、という質問だと思うが。 コード自体は自分で書くのだろう。 369 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:44:14 ] >>368 そう思ってたが >>362 を読んで違うのかと思った 370 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:46:59 ] あらかじめリソース予定地とする空のゴミ領域を作っておいて、 後でマジックナンバーか何かで検索して挿げ替えるとか、かなあ。 371 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:50:07 ] ユーザに差し替えさすならもっと優しい方法にしろ。 自分で埋めるならリンカ使えるだろ 人のアプリをどうこうするなら、Winのリソース差し替えのようにはいかない。 372 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:52:23 ] だからELFの.commentに好きなフォーマットでデータ埋め込んで、 実行時にファイル開いてELFヘッダからその領域を見ればいいんじゃ。 OSのバグ踏む可能性あるけど 373 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:53:02 ] そもそもUNIXの実行ファイルはELFフォーマットなの？ それでいいの？ 374 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:55:52 ] ELFが多いだろうけど全部じゃないんじゃない？ 375 名前：デフォルトの名無しさん mailto:sage [05/03/01 19:59:16 ] UNIXのOSはリソースというものを扱えるの？ もし、OSの支援が無いならば、 実行プロセスが自分自身の元になった実行ファイルの所在を 正確に把握する手段を持たなくてはいけないはず。 これって、少し前に出ていた設定ファイルの議論と重なるような気がする。 376 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:11:33 ] なんでここの連中は仮定で話したがるかね ちゃっちゃと調べて実際をどうなのかを書けよ 377 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:12:56 ] > UNIXのOSはリソースというものを扱えるの？ リソースにもいろいろあるでしょ。 メモリとかディスクとかいったリソースならもちろん扱える。 人的リソースみたいなものは、OSの守備範囲外だから当然無理。 てゆうか、そもそも質問が意味不明。 > 実行プロセスが自分自身の元になった実行ファイルの所在を > 正確に把握する手段を持たなくてはいけないはず。 > これって、少し前に出ていた設定ファイルの議論と重なるような気がする。 実行ファイルのディスク上の物理位置は正確に把握している。 パス名は把握しても意味がない (Windows と違い、実行ファイル のパス名が存在しなくなっても実行を継続できる) から、そんな ものは記録しないってのは、このスレでさんざん既出。 なんか、基本的な素養に欠けているって感じの質問だなあ。 ソースとまでは言わんから、せめて本ぐらい読めというか。 378 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:13:15 ] そうはいかんざき 379 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:13:46 ] >>376 質問スレだから。 質問だけするのが正しい態度。 380 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:14:10 ] >>377 だったら最初からこの本読めとかリンク出せよヴォケ 381 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:14:50 ] で、アイコンとかダイアログのリソースはどっから取ってきてるのかね？ん？ 382 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:16:20 ] ある一人のレスが浮き上がって見える 383 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:16:41 ] >>377 >リソースにもいろいろあるでしょ。 この流れだとWindowsや(旧)Macで言うところのリソースのことではないでしょうか。 >>381 WineではPEファイルから取ってくるみたいですよ。 384 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:18:59 ] たった今、UNIXに挫折したとです。 385 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:20:04 ] UNIXで良書なんて見たことないから どこに載ってるか書いて欲しいなあ。 386 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:20:41 ] >>384 ！！！そのキーワードは、 いっちゃいかん！！ 387 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:21:49 ] WindowsみたいなリソースはOSはサポートしないだろう。 388 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:23:21 ] リソースがなにを指しているか分からないと、 本の名前も出せないでしょ。 >>381みたいな質問している人にOSの本勧めても 無意味だし。 >>381 Xの場合、ダイアローグの表示はツールキットの 仕事なのでツールキットの種類によりけり。 アイコンの表示はウィンドウマネージャの仕事 なので、ウィンドウマネージャによりけり。 (ツールキットが決まると、ツールキット標準の ウィンドウマネージャが決まる場合もある。) 知りたいツールキットとウィンドウマネージャの 種類を具体的に述べれば、もっと具体的な答も 出せるかもね。 いにしえのXtとtwmで言うなら /usr/X11R6/include/X11/{bitmaps,pixmaps}/ と /usr/X11R6/lib/X11/app-defaults/ あたりが 標準的な場所なわけだが。(アプリケーション固有 の場所に置くこともできる。) ツールキットは狭義ではOSの一部ではない。 >>387が言ってるのはそういう意味。 389 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:23:27 ] つか、ELFをばらして好きに弄ってもう一回固めればいいんじゃないの？ 390 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:26:23 ] >>389 わかってないなあ 391 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:27:27 ] UNIXを捨てた おれは正解を選んだ 392 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:28:33 ] 452 名前：デフォルトの名無しさん 投稿日：05/02/28 01:15:33 もうUNIXで仕事したくないのに UNIXの仕事がきます。 どうすればよいですか？ 453 名前：デフォルトの名無しさん 投稿日：05/02/28 01:18:47 仕事があるだけマシってもんよ そうだろう？兄弟 454 名前：デフォルトの名無しさん 投稿日：05/02/28 01:26:38 もういやだ！ もういやだ！ もういやだ！ 393 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:30:51 ] あほくさ 394 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:31:13 ] ELFフォーマットを採用してるOSを上げてください。 自分はLinux以外知りません。 395 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:34:08 ] >>394 商用、フリーを問わず、現役のUNIX系OS、ほぼ全て。 ELF の規格を定めたのは、AT&T と Sun じゃないかな。 linux は最初のうちはa.outしかサポートしてなかったね。 396 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:35:29 ] じゃ、とりあえずELFでトロイ作ってみるよ。 あんがと。 397 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:37:56 ] Windowsヲタは固定観念のかたまりだな... 398 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:38:25 ] >>394 Solaris, *BSD, IRIX, SVR4 等... 最近は組み込み用途の開発ツールも ELF を吐き出す. 399 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:40:27 ] BSD系は最近だな 400 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:42:04 ] CPUの種類やOSの種類が異なると、同じ elf でも 使える命令セットやシステムコールが異なるので、 同一のトロイの木馬を複数のOSに対応させるのは 面倒なんだけどね。まあやれば当然できるが。 つうか、そういうものを作るだけの知恵のある奴は、 ふつうはもう少し建設的なことに暇を使うと思うんだが。 そういう、できて当たり前で、人が困るだけのプログラム を作るのは、そういうことの判断ができない頭弱い奴だけ じゃない？ 401 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:58:38 ] 商用UNIXだとしっかりしてるんだけどね。 402 名前：デフォルトの名無しさん [05/03/01 22:05:13 ] お前ら落ち着け 403 名前：デフォルトの名無しさん mailto:sage [05/03/01 22:09:20 ] さては藻前も釣りだな。 404 名前：デフォルトの名無しさん mailto:sage [05/03/01 22:25:28 ] UNIXにもノートンみたいな製品を進出させるには トロイとかウィルスばらまかないとね 需要のための供給 405 名前：だよもん mailto:だよもん [05/03/01 22:37:03 ] だよもんウィルスだよもん 406 名前：335 mailto:sage [05/03/01 22:49:49 ] １文書に複数文字コードが入ってるとか，そういうややこしいのじゃなくて １文書が１つの文字コードに限定されてるんです． >>341 そうです．自動判別”も”したいんですけど， どうも良いライブラリがみつかんないんですよねぇ． >>344 >文字コードを自動判別しないといけない時点で負け。 orz. 完全に自動判別すんのが厳しいのは分かってるんですけど… 大体でよいんです． >>346 nkfに渡すのも考えてるんですけど… ライブラリ化されてて使いやすいのはないものかと． 407 名前：デフォルトの名無しさん mailto:sage [05/03/01 23:36:56 ] >>335 tricklib.com/cxx/ex/babel/ g++ だと多少問題があるらしいがこれはどうだ？ 僅かな文字数でも高い精度で判別できるぞ。 408 名前：デフォルトの名無しさん mailto:sage [05/03/02 11:14:24 ] コードに日本語でコメントが入っているというだけで 使う気がしなくなるのは俺だけか？ 409 名前：デフォルトの名無しさん mailto:sage [05/03/02 11:23:12 ] ↑ソースクレ厨 410 名前：デフォルトの名無しさん mailto:sage [05/03/02 13:38:21 ] ↑車輪を何度も再発明して貴重な人生を無駄にする香具師 411 名前：デフォルトの名無しさん mailto:sage [05/03/02 15:11:02 ] >>410 ↑見ず知らずの他人の趣味を「人生の無駄」呼ばわりする香具師 412 名前：335 mailto:sage [05/03/02 15:50:59 ] >407 ありがとうございます。よさげですね。 g++だと何か問題があるんですかね？ ちょっと試してみます。 413 名前：デフォルトの名無しさん [05/03/03 23:45:23 ] 414 名前：デフォルトの名無しさん mailto:sage [05/03/05 05:52:29 ] 各種UNIXでcursesの互換性ってどの程度まであるの？ 415 名前：デフォルトの名無しさん [05/03/05 11:28:09 ] 問題ないくらい 416 名前：デフォルトの名無しさん [05/03/07 13:17:21 ] linuxだとアドレス値を整数演算するときに unsigned longに入れてるんだけど、これって 128bitCPUが出てきたときに問題にならないの？ 417 名前：デフォルトの名無しさん mailto:sage [05/03/07 13:30:53 ] 問題になるかならないかは不明。 128bit CPU が実用になる時代が本当に来たとしても、 その CPU で long>=128bit なら問題にならない。 long<128bit なら問題になる。 一般論としては、そういう用途には unsigned long では なく、uintptr_t ないし intptr_t を使うべき。 この型は C99 なら #include <stdint.h> すると定義 される。 418 名前：デフォルトの名無しさん [05/03/07 13:42:04 ] >>416 longを128bitにするから問題なし。 419 名前：デフォルトの名無しさん mailto:sage [05/03/07 13:42:08 ] 仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う ほとんどの場合unsignedにする意味なし Linuxのプロセスメモリマップの使い方でも調べたほうが賢明 420 名前：デフォルトの名無しさん mailto:sage [05/03/07 14:16:30 ] >仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う なんだこりゃ 421 名前：デフォルトの名無しさん mailto:sage [05/03/07 18:18:53 ] >>419 さんは、>>416 さんが 「 unsigned 」 を疑問視されていると受け取られた ようでつね。 対して、多くの方々は >>416 さんが疑問視しているのは 「 long 」 の方だと・・・ どちらにしても、>>417 さんの答えで解決でつよね？ 422 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:12:18 ] UNIXが採用してるLP64というCの型システムだけど、 128bitCPUが出てきたときは、LP128というものを定義して、 unsigned longはつねにポインタサイズと同じビット長になる ことを暗に想定してるのかな？ LP128だと short(16),int(32),long(128),long long(128) こんな感じなのかな？ >>128 >一般論としては、そういう用途には unsigned long では >なく、uintptr_t ないし intptr_t を使うべき。 ですよねえ 423 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:22:13 ] システムによって定義されるのはたった数個の型だけど、 これがいろんな型にtypedefされて、またそれらが インターフェイスの定義に既に使われていたりするところが ややこしいね。 424 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:50:19 ] >>422 予測できる将来に128bit CPUが実現するかどうかは 良く分からないけど、もし実現したらUNIX系は short:int:long:long long=16:32:64:128 になるん じゃないかなあ。だって、1/2/4/8/16 全てのサイズの 整数型が使えないと不便でしょ。 今やuintptr_tがあるから、long がポインタ変数を 保持できるとかいった仮定を設ける必要ないし。 425 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:53:29 ] とりあえず、LP64, ILP64, LLP64, ILP32, LP32くらい理解してからレスしろよ、この屑。 www.opengroup.org/public/tech/aspen/lp64_wp.htm 426 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:19:14 ] LP64・・・longとポインタが64ビットに ILP64・・・intとlongとポインタが64ビットに LLP64・・・long longとポインタが64ビットに ILP32・・・intとlongとポインタは32ビット(今の32bit向けCコンパイラはこれかな？) LP32・・・longとポインタは32ビット、intは16ビット こんな感じ？ 427 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:23:57 ] TRANSITION FROM CURRENT INDUSTRY PRACTICEも読め。 428 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:29:51 ] 128bit化なんてその時になってから泥縄的に考えればいいんだよ。 もし動かなかったらIBMに金出させて力技で修正すればいいだけ。 今困っていない事を今対応するな。これがLinuxのモットーだ。 429 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:33:26 ] 128bit が主流になる頃はおいらは隠居してる. 勝手にやってくれ. 430 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:48:26 ] というか32→64の経験でスキームは固まっている。 431 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:52:54 ] ところでIPV5って64bitだったの? 432 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:01:51 ] つーか128bit時代にもなってLinux使ってたとしたらソフトウェア界の敗北だな。 434 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:02:19 ] > LP64からlongとpointerの相対的関係が異なる だから intptr_t, uintptr_t を使えってばさ。 それで問題なし。 435 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:43:35 ] 32bitマシンって1960年代にできて、64bitマシンって1990年頃 だよね。30年くらいかかっている。 同じような指数的ペースで発展する(1年で1bitくらい)として 128bit マシンができるのは、2050年を過ぎたぐらい… 俺は死んでるな。 436 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:46:46 ] UNIX/Cを潰したいメーカーが96bitマシンとか出して来たりして。 437 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:51:54 ] なぜbit数が増えるのか という根源的な疑問は起きないのか？ 438 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:59:35 ] 基本的にはストレージのサイズが増えるからという要因が 一番大きいでしょ。(AS/400 みたいに、アドレス空間の ほとんどを無駄に捨てざるをえないアーキテクチャだと 話は別だが。) 問題は、現在の指数関数的なストレージサイズの増大が、 あと50年続くかどうかと、たとえ続いたとしても、そんなに 使い道があるかどうかだな。 64ビットでも、人類ひとりひとりに、それぞれ2GB以上も あるというのに。 439 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:02:38 ] いつの時代もそういう近視眼的な発言をする奴がいたわけで 440 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:05:37 ] いつの日にか、家庭向けPCで地球シミュレーションが軽く動く日がくるんだよ 441 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:07:41 ] 昔、12bit マシンってのもあったぞ。 442 名前：429 mailto:sage [05/03/08 01:57:05 ] >>439 438 じゃないんだけど, そのころはおいらは隠居してるわけだ. 興味ねぇ. >>438 > 基本的にはストレージのサイズが増えるからという要因が > 一番大きいでしょ。 数値計算とかやってると, アドレッシングできる領域がどれだけ増 えても実際の計算速度が上がらないと, メリットは小さい. やっと 64bit を有効に使える計算速度に達したってのが現実では? # DB 検索なんかでもそぉだと思うぞ, エンジン作ってる連中にし # てみれば... 443 名前：デフォルトの名無しさん mailto:sage [05/03/08 01:59:32 ] >>429 ダウト。 データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。 444 名前：デフォルトの名無しさん mailto:sage [05/03/08 02:36:39 ] ファイルシステムが2G4G以上をサポートしてる時点で64bit化の恩恵を受けられるわけで。 445 名前：デフォルトの名無しさん mailto:sage [05/03/08 03:12:48 ] >>444 ブー。mmapが使えないと結構苦しい。 446 名前：445 mailto:sage [05/03/08 03:13:48 ] なんか444へのレスとするのは意味不明だな。ごめん。 447 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [05/03/08 05:16:22 ] つまりポインタをlong型で扱う奴はバカint型で扱う奴はもっとバカってことでいいですか？ 450 名前：429 mailto:sage [05/03/08 07:20:28 ] >>443 > データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。 そぉゆう意味で言ってるんだが... 「やっと」ってゆう言い方が悪かった. すまん. おれ的には, やっと 10年くらい前からってな感覚だったもんで... 当初からそれなりに, 64bit マシンはメモリバス帯域広いし, マル チプロセッサ化するために, バスのクロスバ化なんて, ハードウェ ア的に見た場合, 非効率以外のなにもんでも無いようなことまでやっ てるところもあるし... それ以前は, こんなぜいたくはスパコンにしか許されなかったわけ だから... 451 名前：デフォルトの名無しさん mailto:sage [05/03/08 07:39:51 ] pc5.2ch.net/test/read.cgi/tech/1109793931/l50 452 名前：デフォルトの名無しさん [05/03/08 09:07:01 ] printfでtypedefな型を扱えればいいんだが 453 名前：デフォルトの名無しさん mailto:sage [05/03/08 09:12:18 ] >>448 BSDの方の型は、ユーザー空間にも公開しているものなので、 一度決めると変えない方がいいんじゃないかな。まあユーザー プログラムが行儀良く書かれていれば、同じサイズの型に 変えても問題ない筈だけど、行儀良く書かれてない場合、 int と long の食い違いが生じると、lint では警告さえる ケースがありそうな。 あとは、その CPU アーキテクチャの ABI の仕様書に書かれて いる型名に合わせてるとかもあるかも。 Linux の方はカーネル内部用の型に見えるなので、良くわかんない。 454 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [05/03/08 09:43:57 ] >>454 > size_t も "z" 修飾子を使ってどうような > ことができる。 ついでにここも詳しく…… 456 名前：デフォルトの名無しさん mailto:sage [05/03/08 10:48:23 ] 128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは 相当長い間必要ないだろ。データバスが128bitなのはGPUじゃ 当たり前になってるんだろうけど。 16bit -> 32bit アドレス空間は6万5千倍。 32bit -> 64bit アドレス空間は42億倍。 このアドレス空間を使い尽くすのっていつ頃？ ヘタしたら人間が絶滅してるかもなｗ 457 名前：デフォルトの名無しさん mailto:sage [05/03/08 10:49:29 ] >128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは 　　　　　　　　　　　　　　　　　　　↓ 128ビットCPU(データバス幅>=アドレスバス幅=128bit)なCPUは

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef