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

UNIXプログラミング質 ..

357:デフォルトの名無しさん
05/03/01 19:18:15
>>351
だから何ですか？
一般論を聞きたいのではなく、
入れたい場合が出てきたということです。

>>352
詳しく教えてください。

>>354
リンカでどうやって繋ぐのでしょうか？

>>356
初期済みのデータが初期化済みデータのことならその通りです。

358:デフォルトの名無しさん
05/03/01 19:31:03
そういえばX Windowってリソース管理どうなってんの？
アイコンとかって外部ファイル？
もしかしていちいちパス指定で取ってきてる？
パス管理複雑にならない？

359:デフォルトの名無しさん
05/03/01 19:31:28
Cで初期化された大域変数をリンクするのと同じということでは？
ELFの話はLinkers & Loadersていう本にそれなりに載ってる気がする。

360:デフォルトの名無しさん
05/03/01 19:31:52
X or X Window System

361:デフォルトの名無しさん
05/03/01 19:38:33
つまんねー揚げ足すんなよ
おまえ、つまんねー奴って言われるだろ

362:デフォルトの名無しさん
05/03/01 19:39:22
>>359
そういうことでしたら
既存の実行ファイルに対して追加したいので
リンカを使う方法は無理です。

363:デフォルトの名無しさん
05/03/01 19:40:35
>>357
>だから何ですか？
漏れは351じゃないけど、別に多少関連した雑談や世間話くらいしても良いと思うんだけど・・・
質問と回答以外はスレ違い、っていう立場もあるのかもしれないけど。

>リンカでどうやって繋ぐのでしょうか？
テキトーなバイナリなりXMLなり文字列なりをソースとして、
const unsigned char appResourceHoge[] = { 0x11, 0x22, .............. };
みたいなソースファイルを出力するスクリプトなんかを使う。
Xのコードとか書いたことがあればイメージできると思う。
実行ファイルに細工したい（ソース無しでリソースだけ変更したい）って用途には向かない。

なんだから偉そうな質問者様に対してこんな返事しかできなくてごめんね。

364:デフォルトの名無しさん
05/03/01 19:40:43
なあ、俺もUNIXでトロイ作りたいんだけど、
実行ファイルのフォーマット教えてくれよ

365:デフォルトの名無しさん
05/03/01 19:41:29
>>362
ん？既存の実行ファイルを弄らないなら埋め込んでも意味ないだろ？
埋め込んだ上でそれを使うように修正しないと

366:デフォルトの名無しさん
05/03/01 19:41:56
>>363
うわ、そんなことできるならはじめからやってるだよ

367:デフォルトの名無しさん
05/03/01 19:42:53
どうやらここのUNIX使い様はリソースって概念がわからんらしい

368:デフォルトの名無しさん
05/03/01 19:43:23
>>365
Windowsのリソースのように、バイナリに埋め込まれていてかつ後から
編集できるデータ格納方法は無いだろうか、という質問だと思うが。
コード自体は自分で書くのだろう。

369:デフォルトの名無しさん
05/03/01 19:44:14
>>368
そう思ってたが >>362 を読んで違うのかと思った

370:デフォルトの名無しさん
05/03/01 19:46:59
あらかじめリソース予定地とする空のゴミ領域を作っておいて、
後でマジックナンバーか何かで検索して挿げ替えるとか、かなあ。

371:デフォルトの名無しさん
05/03/01 19:50:07
ユーザに差し替えさすならもっと優しい方法にしろ。
自分で埋めるならリンカ使えるだろ
人のアプリをどうこうするなら、Winのリソース差し替えのようにはいかない。

372:デフォルトの名無しさん
05/03/01 19:52:23
だからELFの.commentに好きなフォーマットでデータ埋め込んで、
実行時にファイル開いてELFヘッダからその領域を見ればいいんじゃ。
OSのバグ踏む可能性あるけど

373:デフォルトの名無しさん
05/03/01 19:53:02
そもそもUNIXの実行ファイルはELFフォーマットなの？
それでいいの？

374:デフォルトの名無しさん
05/03/01 19:55:52
ELFが多いだろうけど全部じゃないんじゃない？

375:デフォルトの名無しさん
05/03/01 19:59:16
UNIXのOSはリソースというものを扱えるの？
もし、OSの支援が無いならば、
実行プロセスが自分自身の元になった実行ファイルの所在を
正確に把握する手段を持たなくてはいけないはず。
これって、少し前に出ていた設定ファイルの議論と重なるような気がする。

376:デフォルトの名無しさん
05/03/01 20:11:33
なんでここの連中は仮定で話したがるかね
ちゃっちゃと調べて実際をどうなのかを書けよ

377:デフォルトの名無しさん
05/03/01 20:12:56
> UNIXのOSはリソースというものを扱えるの？

リソースにもいろいろあるでしょ。
メモリとかディスクとかいったリソースならもちろん扱える。
人的リソースみたいなものは、OSの守備範囲外だから当然無理。
てゆうか、そもそも質問が意味不明。

> 実行プロセスが自分自身の元になった実行ファイルの所在を
> 正確に把握する手段を持たなくてはいけないはず。
> これって、少し前に出ていた設定ファイルの議論と重なるような気がする。

実行ファイルのディスク上の物理位置は正確に把握している。
パス名は把握しても意味がない (Windows と違い、実行ファイル
のパス名が存在しなくなっても実行を継続できる) から、そんな
ものは記録しないってのは、このスレでさんざん既出。

なんか、基本的な素養に欠けているって感じの質問だなあ。
ソースとまでは言わんから、せめて本ぐらい読めというか。

378:デフォルトの名無しさん
05/03/01 20:13:15
そうはいかんざき

379:デフォルトの名無しさん
05/03/01 20:13:46
>>376
質問スレだから。
質問だけするのが正しい態度。

380:デフォルトの名無しさん
05/03/01 20:14:10
>>377
だったら最初からこの本読めとかリンク出せよヴォケ

381:デフォルトの名無しさん
05/03/01 20:14:50
で、アイコンとかダイアログのリソースはどっから取ってきてるのかね？ん？

382:デフォルトの名無しさん
05/03/01 20:16:20
ある一人のレスが浮き上がって見える

383:デフォルトの名無しさん
05/03/01 20:16:41
>>377
>リソースにもいろいろあるでしょ。
この流れだとWindowsや(旧)Macで言うところのリソースのことではないでしょうか。

>>381
WineではPEファイルから取ってくるみたいですよ。

384:デフォルトの名無しさん
05/03/01 20:18:59
たった今、UNIXに挫折したとです。

385:デフォルトの名無しさん
05/03/01 20:20:04
UNIXで良書なんて見たことないから
どこに載ってるか書いて欲しいなあ。

386:デフォルトの名無しさん
05/03/01 20:20:41
>>384
！！！そのキーワードは、

いっちゃいかん！！

387:デフォルトの名無しさん
05/03/01 20:21:49
WindowsみたいなリソースはOSはサポートしないだろう。

388:デフォルトの名無しさん
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:デフォルトの名無しさん
05/03/01 20:23:27
つか、ELFをばらして好きに弄ってもう一回固めればいいんじゃないの？

390:デフォルトの名無しさん
05/03/01 20:26:23
>>389
わかってないなあ

391:デフォルトの名無しさん
05/03/01 20:27:27
UNIXを捨てた
おれは正解を選んだ

392:デフォルトの名無しさん
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:デフォルトの名無しさん
05/03/01 20:30:51
あほくさ

394:デフォルトの名無しさん
05/03/01 20:31:13
ELFフォーマットを採用してるOSを上げてください。
自分はLinux以外知りません。

395:デフォルトの名無しさん
05/03/01 20:34:08
>>394
商用、フリーを問わず、現役のUNIX系OS、ほぼ全て。
ELF の規格を定めたのは、AT&T と Sun じゃないかな。
linux は最初のうちはa.outしかサポートしてなかったね。

396:デフォルトの名無しさん
05/03/01 20:35:29
じゃ、とりあえずELFでトロイ作ってみるよ。
あんがと。

397:デフォルトの名無しさん
05/03/01 20:37:56
Windowsヲタは固定観念のかたまりだな...

398:デフォルトの名無しさん
05/03/01 20:38:25
>>394
Solaris, *BSD, IRIX, SVR4 等...
最近は組み込み用途の開発ツールも ELF を吐き出す.

399:デフォルトの名無しさん
05/03/01 20:40:27
BSD系は最近だな

400:デフォルトの名無しさん
05/03/01 20:42:04
CPUの種類やOSの種類が異なると、同じ elf でも
使える命令セットやシステムコールが異なるので、
同一のトロイの木馬を複数のOSに対応させるのは
面倒なんだけどね。まあやれば当然できるが。

つうか、そういうものを作るだけの知恵のある奴は、
ふつうはもう少し建設的なことに暇を使うと思うんだが。
そういう、できて当たり前で、人が困るだけのプログラム
を作るのは、そういうことの判断ができない頭弱い奴だけ
じゃない？

401:デフォルトの名無しさん
05/03/01 20:58:38
商用UNIXだとしっかりしてるんだけどね。

402:デフォルトの名無しさん
05/03/01 22:05:13
お前ら落ち着け

403:デフォルトの名無しさん
05/03/01 22:09:20
さては藻前も釣りだな。

404:デフォルトの名無しさん
05/03/01 22:25:28
UNIXにもノートンみたいな製品を進出させるには
トロイとかウィルスばらまかないとね
需要のための供給

405:だよもん
05/03/01 22:37:03
だよもんウィルスだよもん

406:335
05/03/01 22:49:49
１文書に複数文字コードが入ってるとか，そういうややこしいのじゃなくて
１文書が１つの文字コードに限定されてるんです．

>>341
そうです．自動判別”も”したいんですけど，
どうも良いライブラリがみつかんないんですよねぇ．

>>344
>文字コードを自動判別しないといけない時点で負け。
orz.

完全に自動判別すんのが厳しいのは分かってるんですけど…
大体でよいんです．

>>346
nkfに渡すのも考えてるんですけど…
ライブラリ化されてて使いやすいのはないものかと．

407:デフォルトの名無しさん
05/03/01 23:36:56
>>335
URLﾘﾝｸ(tricklib.com)
g++ だと多少問題があるらしいがこれはどうだ？
僅かな文字数でも高い精度で判別できるぞ。

408:デフォルトの名無しさん
05/03/02 11:14:24
コードに日本語でコメントが入っているというだけで
使う気がしなくなるのは俺だけか？

409:デフォルトの名無しさん
05/03/02 11:23:12
↑ソースクレ厨

410:デフォルトの名無しさん
05/03/02 13:38:21
↑車輪を何度も再発明して貴重な人生を無駄にする香具師

411:デフォルトの名無しさん
05/03/02 15:11:02
>>410
↑見ず知らずの他人の趣味を「人生の無駄」呼ばわりする香具師

412:335
05/03/02 15:50:59
>407
ありがとうございます。よさげですね。
g++だと何か問題があるんですかね？
ちょっと試してみます。

413:デフォルトの名無しさん
05/03/03 23:45:23

414:デフォルトの名無しさん
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:デフォルトの名無しさん
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:デフォルトの名無しさん
05/03/07 13:42:08
仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う
ほとんどの場合unsignedにする意味なし
Linuxのプロセスメモリマップの使い方でも調べたほうが賢明

420:デフォルトの名無しさん
05/03/07 14:16:30
>仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う
なんだこりゃ

421:デフォルトの名無しさん
05/03/07 18:18:53
>>419 さんは、>>416 さんが「 unsigned 」を疑問視されていると受け取られた
ようでつね。
対して、多くの方々は >>416 さんが疑問視しているのは「 long 」の方だと・・・
どちらにしても、>>417 さんの答えで解決でつよね？

422:デフォルトの名無しさん
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:デフォルトの名無しさん
05/03/07 19:22:13
システムによって定義されるのはたった数個の型だけど、
これがいろんな型にtypedefされて、またそれらが
インターフェイスの定義に既に使われていたりするところが
ややこしいね。

424:デフォルトの名無しさん
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:デフォルトの名無しさん
05/03/07 19:53:29
とりあえず、LP64, ILP64, LLP64, ILP32, LP32くらい理解してからレスしろよ、この屑。
URLﾘﾝｸ(www.opengroup.org)

426:デフォルトの名無しさん
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:デフォルトの名無しさん
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までの自然数を素因数に分解して出力しなさい

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

次ページ