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までの自然数を素因数に分解して出力しなさい
誰かＣ言語でプログラム書いてもらえませんか？
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() するべきかどうか分からなくなるがね。
653:デフォルトの名無しさん
05/03/21 13:07:56
>>651
gethostbyname(3)なんかは、「*で返すのはstatic dataだべ」って書いてある。
URLﾘﾝｸ(www.opengroup.org)
のAPPLICATION USAGE
654:デフォルトの名無しさん
05/03/21 13:09:13
>>652
> char * path = "foo/bar";
> char * path_dup = strdup(path_dup);
>
> char * path_dir = dirname(path_dup);
ここでpath_dirの指す先がpath_dupの中かもしれないので
> free(path_dup);
ここでfree()してしまうとpath_dirが使えなくなりませんか？
何かすごくおかしいことを言っているのだろうか・・・
655:デフォルトの名無しさん
05/03/21 13:12:18
>>654
おまえ読解力ゼロ
656:デフォルトの名無しさん
05/03/21 13:26:42
>>654
付け加えると、path_dirは必要ならすぐに自前の領域にコピーしておくこと。
∵basename()を再度呼び出すと上書きされるから。
657:デフォルトの名無しさん
05/03/21 14:02:44
>>652
> char * path_dup = strdup(path_dup);
< char * path_dup = strdup(dup);
通りすがりに、取り合えず訂正しておくわ
658:デフォルトの名無しさん
05/03/21 14:03:51
>>657
m9(^Д^)ﾌﾟｷﾞｬｰ
659:デフォルトの名無しさん
05/03/21 14:05:50
>>657
< char * path_dup = strdup(path);
間違えたわ…ﾊｽﾞ
660:デフォルトの名無しさん
05/03/21 18:31:51
>>652
「静的に割り当てられたメモリ」ってのはライブラリがstaticに持ってるバッファだと
言ってるように読めるんだが（バッファじゃないがerrnoみたいな）。
であるとすれば、free()するとおかしなことになるよな。
>>651が言ってるのはそういうことじゃないの？
661:デフォルトの名無しさん
05/03/21 18:34:51
strdup１つでここまで引きずるとは、さすがUNIX
662:デフォルトの名無しさん
05/03/21 18:42:03
>>660
だから basename の返り値を free しなきゃいいわけで、
basename に与えたポインタを free するのは問題ないだろ？
663:デフォルトの名無しさん
05/03/21 18:58:49
ここは小学生の溜まり場かよ。
664:デフォルトの名無しさん
05/03/23 02:23:26
>>660が正しい。POSIX仕様であっても、basename()は
引数で与えられた領域を上書きすることはない。だから、
上書きされることを気にしてstrdup()する必要もない。
どうもglibc-2.2.1までのPOSIXバージョンは、POSIXの
解釈を間違えていて上書きしてたことがあったようだが。
これはglibc特有のバグで、glibcを使ってなければ関係
ない。>>648の和訳のバグセクションは、そのあたりが
誤訳っぽいな。glibc-2.2.1より後でも問題があるように
読めてしまう。英語マニュアルを見れば明らかなんだが。
665:デフォルトの名無しさん
05/03/23 05:35:24
>>664
POSIXはどうかしらないけど、FreeBSD5.3だと
char * basename(const char *path);
って定義になってるから、引数のバッファは変更されることはなさそうね。
ついでに、返り値は「a pointer to internal static storage space」を返すとなってる。
>>652にあてはめるならこんな感じか。
char * path = "foo/bar";
char * path_dir = strdup(dirname(path));
/* ここでpath_dirを利用 */
free(path_dir);
666:デフォルトの名無しさん
05/03/25 14:31:04
666 ∈（・◎・）∋ 666
667:デフォルトの名無しさん
05/03/26 14:48:43
要するに、basename(3)使うときに、strdupもfreeも要らないわけだ
668:デフォルトの名無しさん
05/03/26 19:16:44
(ﾟДﾟ)ﾊｧ?
669:デフォルトの名無しさん
05/03/27 02:54:15
>>667
うん。ただし、basename(3)を複数回呼んで、その返り値を
後でまとめて使うような場合はmalloc(3)が必要となる。
670:デフォルトの名無しさん
05/03/27 11:34:39
別に固定バッファでもいいわけだが。
671:デフォルトの名無しさん
05/03/29 17:59:02
一つのプログラムファイルからしか使わない構造体があったとして
それをヘッダファイルではなく、foo.cの中で宣言定義するのってのは、
スタイル的に問題ないのでしょうか？
672:デフォルトの名無しさん
05/03/29 18:00:46
ここで質問する事が問題
673:デフォルトの名無しさん
05/03/29 18:36:19
>>672
BSDのソースではあまりみかけないのに、Linuxでは沢山あるので
674:デフォルトの名無しさん
05/03/29 20:13:11
漏れは、他のファイルに見せる必要の無いものは、
実際に見えないようにすべき、と考えます。
unixとは全然関係ないけどね。
675:デフォルトの名無しさん
05/03/29 20:23:30
させたいことと出来ることを一致させるのは大切ですね
676:デフォルトの名無しさん
05/03/30 16:22:54
>>674
俺も ﾉｼ
677:デフォルトの名無しさん
05/03/31 15:18:49
suse9.1上でcを使って、ファイルサイズの取得方法を教えてください
678:デフォルトの名無しさん
05/03/31 15:21:08
>>677
stat()
679:デフォルトの名無しさん
05/04/02 23:47:35
hcreate()ってプログラムの中でひとつのハッシュ表しか使えないんですか？
だとしてこれは役に立つことがあるんでしょうか？
680:デフォルトの名無しさん
05/04/03 01:03:52
そりゃあるでしょ。
複数使いたければ、hcreate_r()使いなよ。
681:デフォルトの名無しさん
05/04/05 01:13:50
hcreate() なんてシラナンダ。自作してた…。
hcreate_r() は GNU 拡張か。
682:デフォルトの名無しさん
05/04/05 01:50:35
>>681
プラットフォームによってはバグってたりするから使わない方がいいよ
追加できるエントリ数にこっそり上限があったり
683:デフォルトの名無しさん
05/04/05 10:51:56
program_a が program_b を呼び出すようにしています．
gdb で program_b の動作をデバッグするには
どうすればいいのでしょう？
684:デフォルトの名無しさん
05/04/05 11:15:04
>>683
program_b の最初の辺りに sleep なり, 入力待ちなりを入れといて,
ps | grep program_b して gdb <pid-of-program_b> する.
どっちかってゆうと, ウニ板のくだ質ネタだが...
685:デフォルトの名無しさん
05/04/05 12:09:45
>>683
"program_b arg1 arg2"
↓
"gdbserver localhost:20000 program_b arg1 arg2"
$ gdb
gdb> target remote localhost:20000
gdb> break xxx
gdb> continue
686:デフォルトの名無しさん
05/04/05 21:37:03
Windowsみたいにcch埋め込みして自動でデバッガ起動とかできないの？
687:デフォルトの名無しさん
05/04/05 21:47:46
core吐いたら、そこからデバッグを再開出来る気もする
688:デフォルトの名無しさん
05/04/06 00:02:56
>>686
こんな感じでいいのか？
以下を実行すると、自身を対象にgdbのウィンドウが立ち上がる。
char pidbuf[20];
snprintf(pidbuf, sizeof pidbuf, "%d", getpid());
if (fork() == 0)
execlp("xterm", "xterm", "-e", "gdb", argv[0], pidbuf, NULL);
sleep(5); /* wait for gdb */
かなーりいい加減な実装だけど。
689:デフォルトの名無しさん
05/04/06 10:45:22
Unixプログラミングを詳しく
網羅した質の高いサイトを
この俺に教えてください
690:デフォルトの名無しさん
05/04/06 11:05:39
つ URLﾘﾝｸ(www.adl.nii.ac.jp)
691:デフォルトの名無しさん
05/04/06 15:24:06
CSVをパースするライブラリくれ
書くのめんどい
つーか、どう考えても世の中に大量にあるだろそんな汎用ライブラリ
どうしてgoogleで引っかからないんだこれ
だれかの陰謀か？ 宇宙人？
692:デフォルトの名無しさん
05/04/06 15:26:47
>>691
perl ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ ruby
URLﾘﾝｸ(search.cpan.org)
693:デフォルトの名無しさん
05/04/06 16:41:41
> perl ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ ruby
> URLﾘﾝｸ(search.cpan.org)
まぬけですね
694:デフォルトの名無しさん
05/04/06 17:24:05
> > perl ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ ruby
> > URLﾘﾝｸ(search.cpan.org)
>
> まぬけですね
まぬけですね
695:デフォルトの名無しさん
05/04/06 17:36:22
Cでくれ
696:デフォルトの名無しさん
05/04/06 17:52:29
一発動かすだけみたいなやつなら perl で十分だろうし、
そうでないなら...
> 691 名前：デフォルトの名無しさん[] 投稿日：2005/04/06(水) 15:24:06
> CSVをパースするライブラリくれ
> 695 名前：デフォルトの名無しさん[sage] 投稿日：2005/04/06(水) 17:36:22
> Cでくれ
この間になんぼでも書けるだろう。
697:デフォルトの名無しさん
05/04/06 18:28:29
C-- (C Decre)
698:デフォルトの名無しさん
05/04/06 21:04:08
>>691
何故みつからないかというと、みんなが納得する"CSV"という
名前のフォーマットは存在しないからです
標準化されていない悲しさよ
699:デフォルトの名無しさん
05/04/06 21:24:12
そんなことなかろう。
google で
"comma separated value" parse library
を検索すると見つかるぞ。
単に探し方が悪いだけだと見た。
700:デフォルトの名無しさん
05/04/06 23:00:19
CSVって、
・フィールド,で区切られている。
・#から改行までは無視。
・,#をデータに入れたい時は、"tell your #, please!"とクォート。
・レコードは改行で区切られている。
が典型的かな。
>>698
色々と問題が起きそうなのは、
・改行コード。
・ISO-2022-JPの様な左面の文字集合切り替えのある場合。
かな。
701:デフォルトの名無しさん
05/04/06 23:08:41
>>700
> ・,#をデータに入れたい時は、"tell your #, please!"とクォート。
ﾏｼﾞかよ
そんなエスケープ初めて聞いた
702:デフォルトの名無しさん
05/04/07 09:11:15
CSV
・１行で１レコード。
・コンマ「，」をデリミタとして値を区切る。
・値にコンマが含まれているときにはダブルクォート「”」で括る。
・値にダブルクォートが含まれているときは「””」と２重にする。
多少の方言はあるけど、だいたいこんなんが基本。
というのが漏れの理解。
703:デフォルトの名無しさん
05/04/07 09:41:22
値に「"」が含まれていたら「''」でクォートとか、「\」でエスケープとか、
文字列フィールドに数字しかないときは「'」が先行するとか、
微妙にいやらしい方言が多いんだよね。
704:デフォルトの名無しさん
05/04/07 10:12:33
だからライブラリが無いｗ
705:デフォルトの名無しさん
05/04/07 12:35:08
""の中に改行が含まれるケースもある
1,"abc","def",ghi,1111
2,"abc","This is a quoted
string.",def,234
3,"abc
def","hoghoge",aaa,234
みたいな
706:デフォルトの名無しさん
05/04/07 14:22:07
>>705
lex 辺りでアナライザーはかせりゃ, 悩むほどのもんじゃねぇだろ?
あとは, yylex 呼ぶループ書くだけ.
707:デフォルトの名無しさん
05/04/07 14:30:47
この程度、lex 使わずに手書きしても全然たいしたことない。
この程度が書けないような香具師は、Cを使うのはやめて、
Java とか Perl とか Python とか Ruby とか VB に転向すべき。
708:デフォルトの名無しさん
05/04/07 14:32:23
Perl なら
URLﾘﾝｸ(www.din.or.jp)
PHP なら
URLﾘﾝｸ(jp.php.net)
があるけどね
709:デフォルトの名無しさん
05/04/07 15:00:15
メールサーバでReceived:の項にJSTなどとタイムゾーンが文字で入りますが、あれは取得できる物なのでしょうか？
それとも、メールサーバのプログラムの中にそのようなテーブルがあるのでしょうか？
710:デフォルトの名無しさん
05/04/07 15:02:40
>>707
> この程度、lex 使わずに手書きしても全然たいしたことない。
ゴリゴリ手書きして遅いルーチンを書くのはいとも簡単だけど、
(f)lexと同等かそれ以上に高速なものにしようとすると結構大変かも。
711:デフォルトの名無しさん
05/04/07 15:04:59
>>709
echo $TZ
712:デフォルトの名無しさん
05/04/07 15:06:37
echo OTZ
713:デフォルトの名無しさん
05/04/07 15:36:01
>>710
トークンの種類が非常に多く、DFAのメリットが効いてくる
ような場合なら、確かに (f)lexの方が速くなるが、この例
だと共通プレフィックスになるような文字列は全くないので、
まともなプログラマが書けば、どう転んでも手書きの方が速い。
もちろん、まともじゃないプログラマなら話は全然別。
714:デフォルトの名無しさん
05/04/07 16:01:55
>>713
へっ？字句解析でDFAの表引きが効率向上に役立つ割合なんてほんの僅かです
が。字句解析器生成が手書きよりもうれしいのは、まず第一にバッファリング
(と先読み管理)をそれなりにきちんとやってくれるからですけど。もちろんき
ちんと最適化したマニュアルの解析器の方がバッファリングも速いけど、それ
はそれで「どう転んでも」速くなるほど自明じゃない。
715:デフォルトの名無しさん
05/04/07 16:12:37
うーん、ほとんどの言語は、そもそもそんな高度な
バッファリングなんていらないでしょ？ 一文字バッ
ファリング、すなわち ungetc() で十分なことが
多いと思うけど。そりゃたまには、そうじゃない
変態文法もあるけどさあ。
今回の CSV も ungetc() で十分なので、バッファ
リングで遅くなる要素は、まったくないと思うけど？
716:デフォルトの名無しさん
05/04/07 18:08:46
おまいらは読込速度が問題になる程
大量の CSV を読もうとしてるのか…ッ！
こないだいたけどね。
「いやー Excel で開けないくらいでっかくなっちゃいましたよﾊｯﾊｯﾊ」
とかいうから、行数カウントしてみたら 1200万行。
717:デフォルトの名無しさん
05/04/07 18:54:46
そこまで多くなったらDB使えと小一時間(ry
718:デフォルトの名無しさん
05/04/07 20:36:51
CSVやめてS式にしようぜ
719:デフォルトの名無しさん
05/04/07 21:00:27
字句解析器がバッファリングをするって何の話だよ？？
720:デフォルトの名無しさん
05/04/07 21:21:46
UNIXプログラミングに関係ないはなししはよそでおねがいします。
721:デフォルトの名無しさん
05/04/07 21:53:30
XMLに決まってんジャンｗｗ
722:デフォルトの名無しさん
05/04/08 00:09:41
LALRのLAじゃないの？＞バッファリング
723:デフォルトの名無しさん
05/04/08 00:40:39
LALR使ってるのはlexじゃなくてyaccでそ。
724:デフォルトの名無しさん
05/04/08 01:39:56
Unix でプログラミングなら, あるもの使えば?
車輪の再発明の必要もないし...
ってな, つもりで >>706 を書いたんだが, 妙なことになってるしorz
>>720
> UNIXプログラミングに関係ないはなししはよそでおねがいします。
おもいっきり, UNIXプログラミングの*はなしし*だと思うが...
つか, UNIXプログラミングの*はなしし*をすれば, この程度は普通
だと思うぞ.
725:デフォルトの名無しさん
05/04/08 03:10:14
>>720 はCSVがUNIXに関係ないと思ってる香具師
726:デフォルトの名無しさん
05/04/08 03:38:49
>>709
fURLﾘﾝｸ(elsie.nci.nih.gov)
727:デフォルトの名無しさん
05/04/08 03:39:31
>>709
URLﾘﾝｸ(david.tribble.com)
728:デフォルトの名無しさん
05/04/08 09:32:37
>>725
関係無いだろ
729:デフォルトの名無しさん
05/04/08 11:46:01
yacc/lexがなきゃCSV も読めないのか、ここの連中は（笑）
火炎放射器でタバコに火を付けるってのはこういうのを言うのかね。
730:691
05/04/08 13:46:41
そういうのを自分で作るのが面倒だという話なんだ
誰かが作ったものがそこらに転がってるなら
火炎放射器でもなんでも使うよ。
731:デフォルトの名無しさん
05/04/08 14:42:40
cut(1) ですむところを awk や perl でやったりもするけど別にええやん
732:デフォルトの名無しさん
05/04/08 14:50:36
awkは兎も角、perlは…
まぁいいか。
>>730
火炎放射器使うくらいなら私は自分で火を熾すよ。
733:デフォルトの名無しさん
05/04/08 14:58:36
>>732
> 火炎放射器使うくらいなら私は自分で火を熾すよ。
野蛮だなｗ
734:デフォルトの名無しさん
05/04/08 15:14:19
火炎放射器を使う方がむしろ野蛮だと思いまつ。
つうか、これぐらい単純な処理だと、lex使う方
がむしろ面倒だと思う。
735:デフォルトの名無しさん
05/04/08 15:50:40
簡潔な方法が正解かと
736:デフォルトの名無しさん
05/04/08 16:11:18
simple is beauty が UNIX
737:デフォルトの名無しさん
05/04/08 18:39:06
なんだよお前らそんなに車輪作りたいのか？
おれはやだぜ
738:デフォルトの名無しさん
05/04/08 18:50:53
任意個の整数の合計を求めるライブラリくれ
書くのめんどい
つーか、どう考えても世の中に大量にあるだろそんな汎用ライブラリ
どうしてgoogleで引っかからないんだこれ
だれかの陰謀か？ 宇宙人？
739:デフォルトの名無しさん
05/04/08 18:55:42
そんなのライブラるまでもないからだろ
740:部外者でけどね
05/04/08 19:24:44
こんなのは setjump / longjump のいい練習になるかな。遊びでつくてみよ。
741:デフォルトの名無しさん
05/04/08 19:32:59
>>740
整数の合計を求めるのにsetjump/longjump?
>>739, >>738
std::accumulate()
742:デフォルトの名無しさん
05/04/08 19:39:11
Cでくれ
743:デフォルトの名無しさん
05/04/08 20:18:25
>>738=740はただの初心者
744:デフォルトの名無しさん
05/04/08 20:23:22
#define goukei(arr) { int i; extern int g_goukei; for(i=0, g_goukei; i<sizeof(arr)/sizeof(arr[0]); i++) g_goukei+=arr[i]; }
745:デフォルトの名無しさん
05/04/08 20:27:16
UNIXでまともな言語ってJavaぐらいしかない
746:デフォルトの名無しさん
05/04/08 23:34:30
はつみみです
747:デフォルトの名無しさん
05/04/10 18:06:28
>>737
自分の回りに車輪が見当たらなければ作るしかねーだろが。
748:エラー処理ブッチご容赦
05/04/10 23:57:43
>>740
#include <setjmp.h>
#include <stdio.h>
void acc1(int n, int x, jmp_buf env) {
if (n == 0) { longjmp(env, x); }
else { acc1(n - 1, n + x, env); }
}
int acc(int n) {
jmp_buf env; int x;
if (n == 0) { return 0;}
else if (x = setjmp(env)) { return x; }
else { acc1(n, 0, env); }
}
int main(int argc, char *argv[]) {
printf("%d\n", acc(atoi(argv[1])));
}
749:デフォルトの名無しさん
05/04/11 08:01:46
誰か、>748が何をしたいのか教えてくれ。
750:デフォルトの名無しさん
05/04/11 08:30:25
>>749
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char ** argv) {
printf("%d\n", atoi(argv[1]) * (atoi(argv[1]) + 1) / 2);
return 0;
}
751:デフォルトの名無しさん
05/04/11 09:27:35
やあおまいら。C言語の勉強ははかどってるかね？
752:デフォルトの名無しさん
05/04/11 09:39:22
>>750
それのどこが「任意個の整数の合計」なんだか。
つーか、>740=>748が阿呆なだけか。
753:仕様書無しさん
05/04/19 00:40:02
>>740
setjmp 使ってなくてすまん。
int
summers (int n, ...)
{
va_list ap;
int i = 0, sum = 0;
va_start (ap, n);
while (i++ < n)
sum += va_arg (ap, int);
va_end (ap);
return sum;
}
754:デフォルトの名無しさん
05/04/19 20:26:29
だめだよぉ
setjmp使わなきゃ
755:デフォルトの名無しさん
05/04/21 15:45:47
Linux です．
ある実行ファイルを実行している最中で，
このファイルを open することはできますか？
756:デフォルトの名無しさん
05/04/21 15:48:58
>>755
自分で試せ。
757:デフォルトの名無しさん
05/04/21 15:50:00
>>755
こんにちはLinuxさん
758:デフォルトの名無しさん
05/04/21 15:50:17
>>755
このファイルとは、実行中の実行ファイルのことでしょうか。
それなら制限つきでopenできるはずです。
759:デフォルトの名無しさん
05/04/21 15:56:14
>>758
制限って？
760:755
05/04/21 16:13:06
説明が足りませんでした
ある実行可能ファイルを open したところ
失敗して，strerror(errno) したところ
Text file busy
とでるんです(バイナリファイルなのに…)
これはそのファイルが実行中と解釈していいのでしょうか？
761:デフォルトの名無しさん
05/04/21 16:38:39
>>760
LinuxさんはどんなUNIXを使ってらっしゃるんで?
762:デフォルトの名無しさん
05/04/21 17:05:16
書き込みモードで開こうとしてない？
あと text はコードというような意味。
バイナリファイル/テキストファイルというような区別はUnixにはない。
使用中なのは確かだけど実行中かどうかは知らん。
763:デフォルトの名無しさん
05/04/21 17:07:06
Text file busy どこで拾ってきたLinuxなんだろ
764:デフォルトの名無しさん
05/04/21 17:15:21
少なくとも BSD 系では errno 26 は "Text file busy."
765:755
05/04/21 17:18:53
いろいろどーもす
参考になりますた
> errno 26 は "Text file busy."
Linux でも同様です
766:758
05/04/21 18:28:40
>>759
既に答えが出ているからいいよね。
fopen("実行モジュール", "w");
とすると楽しいことになる。
767:デフォルトの名無しさん
05/04/21 20:41:01
>>766
そんなもん想定の範囲内だが？
768:デフォルトの名無しさん
05/04/21 20:47:43
楽しかった！
もっとやって！
769:デフォルトの名無しさん
05/04/21 23:40:28
Windowsのdllやexeは使用中に更新出来ないが
UNIXの実行ファイルは更新可能
770:デフォルトの名無しさん
05/04/21 23:43:56
実行中に削除って…なんか指令を伝えた後に爆発するレコードみたいだな
771:デフォルトの名無しさん
05/04/22 00:20:08
プロセス終了時にコア吐くですよ。
772:__
05/04/22 00:40:24
>>760
んー、こういうことかな？
#include <stdio.h>
int
main (int argc, char **argv)
{
FILE *fp;
if ((fp = fopen (argv[0], "w")) == NULL)
perror ("fopen"), exit (1);
fclose (fp);
return 0;
}
$ gcc -Wall -o Text Text.c
$ ./Text
fopen: Text file busy
$
773:デフォルトの名無しさん
05/04/22 09:39:12
>>772
良い例です（笑）。細かな事ですが、コマンド名には大文字を入れないのが慣習です
774:デフォルトの名無しさん
05/04/22 11:36:45
select でパイプからの入力待ちをしたのですが
待ち時間を 10 秒とかにしているのに
すぐに 0 が返ってきます
時間切れ以外に 0 が返ってくる場合はありえるのでしょうか？
man select には時間切れと書いていますが
775:デフォルトの名無しさん
05/04/22 11:54:38
タイムアウトの指定の仕方が間違っている！（ｗ
776:デフォルトの名無しさん
05/04/22 12:18:55
>>774
待ち時間の設定から呼び出しまで辺りのソースを晒して味噌。
777:デフォルトの名無しさん
05/04/22 20:23:18
会社のソースなので外部に持ち出せません
契約違反になります
778:デフォルトの名無しさん
05/04/22 20:26:26
ﾊﾞｲﾊﾞｲ
779:__
05/04/22 20:54:02
>>777
へたれよのぅ。
780:デフォルトの名無しさん
05/04/23 05:05:53
それ以前にそんな奴が2chで質問するなと。
781:デフォルトの名無しさん
05/04/25 11:15:17
とあるプログラムをつくっていて
(1) Redhat 7.1
(2) Redhat EL WS
で動作が違いました．
すでに実行中のファイルを書きこみ専用で
open しようとしたときに
(1)では成功，(2)では失敗します．
このようなことはありえますでしょうか？
これは OS 自体の設定の違いによって起こるものなのでしょうか？
また，ファイルパスを指定して，
それが実行中かどうかを知る方法(もちプログラムの中で)は
ありますか？
782:デフォルトの名無しさん
05/04/25 11:54:35
その辺はLinux板だなあ。UNIX一般の問題じゃないから。
execve(2)した時の、O_EXEC, MAP_DENYWRITE関係の設定が変ったんだろ。
書けるとsecurity holeになるからね。十分あり得る。
$ cat /proc/プロセスID/maps
してみてね。
783:デフォルトの名無しさん
05/04/25 12:42:32
>>782
本当にそうなら、これでまたひとつWindowsに近づいたな。
784:781
05/04/25 12:48:45
失礼しますた
Linux 板にいてきます
785:782
05/04/25 12:55:58
>>783
遠退いたんでしょ?
786:デフォルトの名無しさん
05/04/29 16:02:44
サーバのプログラムはアイドル時どのように、待っているのでしょうか？
sleepを入れながらポーリングするのでしょうか？
787:デフォルトの名無しさん
05/04/29 16:06:08
何するものかによって違うけど、普通は select とかだろうね。
788:デフォルトの名無しさん
05/04/29 16:09:48
>>786
ポーリングでしか分からないのなら、それもあり。
でも定期的に無駄にCPU使うので、可能なら
accept なり、read なりでイベント待ちするのが普通
789:デフォルトの名無しさん
05/05/01 10:11:26
Linuxでのプログラミング学習です。
こんな問題をいきなり授業で出題されました。
まだほとんど何もやってないので、さっぱり
意味が分かりません。分かる方がいらっしゃるなら、
回答の方教えてはいただけませんか？
f(x)=xの2乗-xy-yの2乗 について
x=-0.423 y=1 の時の値を(小数点第4位までの表示)
で求めなさい。ただし、変数x,yの値はscanf文で
入力させてください。
790:デフォルトの名無しさん
05/05/01 10:15:54
アナタとワタシはスレ違い。
791:デフォルトの名無しさん
05/05/01 10:20:48
GTK プログラミング！！
で聞けばいいんですかね？
792:デフォルトの名無しさん
05/05/01 10:37:11
>>789
perl -e '$x=scanf();$y=scanf();printf "%.4f\n",$x**2-$x*$y-$y**2;sub scanf {<>}'
793:デフォルトの名無しさん
05/05/01 11:20:35
>>789
お好きなところへどうぞ。
ｽﾚﾘﾝｸ(tech板)
ｽﾚﾘﾝｸ(tech板)
794:デフォルトの名無しさん
05/05/01 12:11:43
ありがとうございました
795:从*･ ｡.･) ◆SayuminPM.
05/05/01 21:46:42
Advanced Programming in the UNIX(R) Environment (2nd Edition)
URLﾘﾝｸ(www.amazon.com)
みんな予約した？
796:デフォルトの名無しさん
05/05/01 22:50:17
そんな消え行く過去の遺産の本はもういらん
第１版で十分
797:デフォルトの名無しさん
05/05/01 23:19:31
”そんな消え行く過去の遺産の” と "はもういらん"
は不必要
798:デフォルトの名無しさん
05/05/01 23:38:03
今住んでいるところで現物見れそうもないんで、
とりあえずレビューされてから考えようかな、と。
第1版は持ってるし。エラッタ修正待ちも兼ねて。
799:デフォルトの名無しさん
05/05/01 23:42:31
>>797
本
第１版で十分
800:デフォルトの名無しさん
05/05/02 00:07:33
$ cat >>799 | grep "で" | awk -F'版|十' '{ print $2"？" }'
801:デフォルトの名無しさん
05/05/02 00:26:02
ﾜﾛﾀ
802:デフォルトの名無しさん
05/05/02 00:45:05
>>800
>799は>797の指示に従ったんだろ。
803:デフォルトの名無しさん
05/05/02 00:54:40
>>798
×エラッタ
○イレイタ
○エラータ
804:デフォルトの名無しさん
05/05/02 03:53:51
もはやカタカナ表記はエラッタでいいんじゃないの?
UNIXをユニックスと書くやつはいてもユーニクスとは誰も書かないのと同じで。
803は現代日本で生きるのは大変そうだな。
明治時代なら好きな読みを押し付けられたのに。
805:デフォルトの名無しさん
05/05/02 03:59:28
>>804はアイロンとか使えないんだよ。
806:デフォルトの名無しさん
05/05/02 04:20:02
急速にスレの質が低下してまいりました
807:デフォルトの名無しさん
05/05/02 19:52:24
いや、最初からこんな感じだったよ
808:デフォルトの名無しさん
05/05/02 19:56:03
バケラッタ
809:デフォルトの名無しさん
05/05/04 16:07:05
c++(gcc)での実行ファイル名（つまり自分自身のファイル名）の取得方法を教えてください
810:デフォルトの名無しさん
05/05/04 16:07:46
argv[0]
811:デフォルトの名無しさん
05/05/04 16:12:01
このスレにあったような。
812:デフォルトの名無しさん
05/05/05 23:01:54
質問です。
fork/execして生まれた子が親の死を感知する方法で一般的な
方法はあるのでしょうか？(initに引き取られると困る)
調べると「システムによってはSIGHUPが...」とかという記述で
一般的な方法は見つかりませんでした。
もちろん、「そんな親プログラムを作るな」というのは承知しているのですが...
813:デフォルトの名無しさん
05/05/05 23:17:20
ないんじゃないでしょうか。
どうしても知りたければお爺さんプロセスから教えてもらうようにするとか。
ちなみにSIGHUPは親プロセスの死とは直接関係ないですよ。
814:デフォルトの名無しさん
05/05/05 23:38:01
ncursesを使ったソースでなるべくシンプルなものってないでしょうか
お手本にしたいのですが
815:デフォルトの名無しさん
05/05/05 23:43:53
$ cd ncurses-5.4/test
$ ls
Makefile.in README aclocal.m4 background.c blue.c
bs.6 bs.c cardfile.c cardfile.dat color_set.c
configure* configure.in demo_defkey.c demo_forms.c demo_keyok.c
demo_menus.c demo_panels.c ditto.c dots.c edit_field.c
edit_field.h filter.c firework.c firstlast.c gdc.6
gdc.c hanoi.c hashtest.c ins_wide.c inserts.c
keynames.c knight.c listused.sh* lrtest.c modules
ncurses.c ncurses_tst.hin newdemo.c railroad.c rain.c
tclock.c test.priv.h testaddch.c testcurs.c testscanw.c
tracemunch* view.c worm.c xmas.c
816:デフォルトの名無しさん
05/05/06 00:17:10
>>812
親のみが書き手、子が読み手のpipeを用意する。
親が死んだら子によるread(2)の返り値が0になるはず。
とか。一般的かどうかは知らない。
817:812
05/05/06 00:35:30
>>813
>>816
レスありがとうございます。やはり一般的な方法はないですか・・・
パイプとかPID監視とかの代替案を使うことにします。
818:デフォルトの名無しさん
05/05/06 01:09:12
>>812
> (initに引き取られると困る)
ここが引っ掛かっていてスルーしていたんだけど、
これどういう意味なの? 何が困るの?
pollingでいいなら、IPCのセマフォ使うとか。
819:デフォルトの名無しさん
05/05/06 01:17:25
URLﾘﾝｸ(p231.net220148094.tnc.ne.jp)
ｗｗｗｗｗｗっｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗうぇｗｗｗうはっｗｗｗっ
おｋｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
820:デフォルトの名無しさん
05/05/06 03:26:12
>>812
kqueue/keventがあるOSなら任意のpidのexitしたのがわかる。
821:デフォルトの名無しさん
05/05/06 06:08:03
>>812
適当にシグナル投げてみるとかは?
822:デフォルトの名無しさん
05/05/06 06:24:26
>>821
能動的にアクション起こしていいんなら getppid()!=1 で十分だろう
823:デフォルトの名無しさん
05/05/07 02:48:42
wchar_t wb[] = L"ほげ";
printf("%S",wb);
や
wchar_t wb[20];
initscr();
getn_wstr(wb, 20);
printw("%S",wb);
は問題なし
wchar_t wb[] = L"ほげ";
initscr();
printw("%S",wb);
は
^[$B$[$2^[(B
こんな風に表示されてしまう
setlocale(LC_ALL, "");してみても変化無し
何が足りないんでしょう
824:デフォルトの名無しさん
05/05/07 03:05:39
シェルで日本語出すように設定してないだけじゃねーの？
825:デフォルトの名無しさん
05/05/07 07:14:54
出力はISO-2022-JPに見える。
ターミナルのlocaleはそれでいいのか？
826:デフォルトの名無しさん
05/05/07 18:29:50
>>822
getppidなんてはじめて知った
おくがふかいなぁ
827:デフォルトの名無しさん
05/05/10 07:09:50
プロセス間でデータをやりとりするにはどうしたらよいのでしょうか？
WindowsにおけるWM_COPYDATAのような方法を探しているのですが。
828:デフォルトの名無しさん
05/05/10 08:35:35
親子、あるいは親戚関係にあればpipe(2)、
そうでなければmmap(2)、IPC共有メモリなど。
829:デフォルトの名無しさん
05/05/10 16:03:44
Xwindowで動作するプログラムを作りたいのですが、どこから勉強していけばよいのでしょうか？
C++でコマンドラインプログラムは書けます。
830:デフォルトの名無しさん
05/05/10 17:30:24
今さらXlibでもあるまいから、まずは使うGUIツールキットを決めなされ。
多分GTK+かQtのどちらかになると思うけど。決まったらそのスレへgo!
831:デフォルトの名無しさん
05/05/10 20:00:24
widestudio とかもあるよ
832:デフォルトの名無しさん
05/05/10 20:02:45
最近良く見かけるが、WideStudio の中の人は 2ch で宣伝する方針なのか?
833:デフォルトの名無しさん
05/05/10 20:26:28
Motifを忘れているよ。
UNIXなら標準だし、ついでにXlibにも詳しくなる。
834:デフォルトの名無しさん
05/05/10 20:30:23
いつのまに標準になってたのか
835:デフォルトの名無しさん
05/05/10 20:46:32
Motifはどさ回りの仕事量が増えるけどねぇ。
ツールキットとしては古くて資料も色々あるけど。
それにしても、関数名が長いし。
#XmToggleButtonGadgetGetState()とかw
836:デフォルトの名無しさん
05/05/10 20:59:48
>>833
>ついでにXlibにも詳しくなる。
詳しくないと使えないっつーか
だから避けられるんだっつーか
…折れ線グラフひとつ書くのも一苦労でしたよ、ええ。
837:デフォルトの名無しさん
05/05/11 00:27:26
C++だからQtかgtk--のどちらかだろう。
俺としてはmoc拡張の必要のないgtk--を推奨。
URLﾘﾝｸ(www.geocities.com)
↑を眺めてみるのもよし
838:デフォルトの名無しさん
05/05/12 23:46:19
おれならまずXでGUIアプリなんて作らないな
839:デフォルトの名無しさん
05/05/14 03:01:37
あるプロセスIDのプログラムが実行中かそれとももう終了したのかを確認するにはどうしたらよいのでしょうか？
840:デフォルトの名無しさん
05/05/14 03:31:32
詳解Unixプログラミングを読むのが一番早い。
841:デフォルトの名無しさん
05/05/14 04:19:01
それくらいならFAQにも出てたと思う。
842:８３９
05/05/14 04:48:27
/procディレクトリの中のPIDと同じファイルが存在すれば、実行中であると判断しても問題ないでしょうか？
実行が終了すれば必ず消えるものなのでしょうか？
843:デフォルトの名無しさん
05/05/14 06:18:25
kill 839
844:デフォルトの名無しさん
05/05/14 06:20:14
>>839
kill(pid, 0)
845:デフォルトの名無しさん
05/05/14 06:20:43
間違えた。
kill(839, 0)
846:デフォルトの名無しさん
05/05/14 06:36:23
まあ、FAQによれば
killよりも/procの方が確実に判定できるケースがあるとのことだから
そのやり方について聞いているんだろう。
実装(環境)依存としか答えようがなさそうだけど。
関係ないけど、「実行中である」という確実な判定は不可能だな。
なんらかの呼び出しから制御が戻る前に終了する可能性がある。
PIDの唯一性(再割り当てされないこと)が保証されていれば
「終了した」ということは判定できるだろうけど。
847:デフォルトの名無しさん
05/05/14 06:39:19
fork() 関数で子プロセスを生成しました。
親プロセスは、一秒に一回ぐらいの間隔で、子プロセスが終了してるかどうかを確認したいのです。
その間、親では
while(1){
子プロセスの終了してるか監視 終了してれば、処理を抜ける
メータ表示
}
などのプログラムを動かしたいと思っています。
いろいろ調べたんですがwait()関数なるものが子プロセス終了まで待ちつづけるというものでしたので、子プロセスが動いている間
メータを動かすという処理が出来ませんでした。
子プロセスは、system関数で、別のプログラムを実行しています。
その間、親プロセスで、メータを増やす処理をしたいのですが、子プロセスが終了？してるか調べるwait関数に変わるものは何かあるのでしょうか？
ps -aux で確認したところ、子プロセスの処理が終わったらゾンビプロセスになってました；
848:デフォルトの名無しさん
05/05/14 06:56:45
おまえはタイトルも>>1も読まないだけでなく
最近の10レスも読まないのな
849:デフォルトの名無しさん
05/05/14 07:41:43
>848
別のスレでもご迷惑をかけました
勝手に書き込んで荒らしてしまって、
すみませんでした自分で調べてみます。
申し訳ありませんでした。
>おまえはタイトルも>>1も読まないだけでなく
>最近の10レスも読まないのな
これからは、すべて読んでから書き込みます。
すいませんでした。
850:デフォルトの名無しさん
05/05/14 07:43:25
なんで伝統伝説のUNIX板に聞かないの？
851:デフォルトの名無しさん
05/05/14 08:16:29
UNIX板気持ち悪いので
852:デフォルトの名無しさん
05/05/14 09:54:10
>>847
wait3(2)かwait4(2)で、WNOHANG
853:デフォルトの名無しさん
05/05/14 13:02:59
busy loopなんかするな馬鹿
854:デフォルトの名無しさん
05/05/14 21:11:45
>>847
なんだそれは？その子プロセスは直接の子では無いではないか。
素直にAPUEを嫁
855:デフォルトの名無しさん
05/05/14 21:15:06
メータって。プログレスバーじゃねぇの？
856:デフォルトの名無しさん
05/05/14 22:40:27
sleepをミリ秒単位で実行する方法を教えてください
857:デフォルトの名無しさん
05/05/14 22:59:42
>>856
usleep
858:デフォルトの名無しさん
05/05/14 23:03:30
>>857
ありがとう
859:デフォルトの名無しさん
05/05/14 23:09:50
>>856
nanosleep
860:デフォルトの名無しさん
05/05/14 23:57:59
select
861:デフォルトの名無しさん
05/05/15 11:17:57
社のUNIX遣いの口癖が「だからぁ、子を先に殺すんだよｗ」なんです。いつも半笑いで。
通報したほうがいいですか？
862:デフォルトの名無しさん
05/05/15 12:15:06
つまらん。勝手にすれば。
863:デフォルトの名無しさん
05/05/15 13:05:55
あひゃひゃ
864:デフォルトの名無しさん
05/05/15 13:33:11
CPUの個数を取得する方法を教えてください
865:デフォルトの名無しさん
05/05/15 15:41:24
ケースの蓋を開けて目視で確認してください
866:デフォルトの名無しさん
05/05/15 15:52:40
最近は目視じゃ不十分だな
867:デフォルトの名無しさん
05/05/15 15:54:26
BSD系だと sysctl でわかったりする。
Linuxは知らないけど /proc の下あたりになんかあるんじゃ？
いずれにしても移植性はないと思う。
868:デフォルトの名無しさん
05/05/15 16:58:19 BE:50674853-
/proc/cpuinfo
869:デフォルトの名無しさん
05/05/15 17:16:43
HTだとわからんな
870:デフォルトの名無しさん
05/05/16 01:38:20
HTでも/proc/cpuinfoに出るぞ
871:デフォルトの名無しさん
05/05/16 02:05:21
UNIXでWindowsのDLLの動的ロードのようなことはどのようにやるのでしょうか？
872:デフォルトの名無しさん
05/05/16 02:13:11
>>871
dlopenとかの事？
873:デフォルトの名無しさん
05/05/17 02:49:38
UNIXでWindowsのDLLのDllMainのようなことはどのようにやるのでしょうか？
874:デフォルトの名無しさん
05/05/17 02:52:05
どういう挙動を望んでいるのかをなぜ自分で説明しないのだろうか?