C言語なら俺に聞け 156

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ﾜｯﾁｮｲ 9bb7-/QqT)
垢版 |
2020/09/28(月) 14:41:30.00ID:QxfbhGyV0
!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 155
https://mevius.5ch.net/test/read.cgi/tech/1589120427/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
430デフォルトの名無しさん (ﾜｯﾁｮｲ 468c-qdLU)
垢版 |
2021/01/05(火) 18:35:11.65ID:zMZuOoIk0
>>423
読む人がいないならメッセージも無意味.
2021/01/05(火) 18:47:10.76ID:oFYQTpSv0
確保できないと返ってくれば対処方法はあるだろう
OK返されたあと、実際に使おうとしたら実はってなると
その分リカバリーが複雑になる
2021/01/05(火) 19:00:03.87ID:K71kt7oj0
ここの人はOOM Killerも知らんのか？
確保したプロセスが死ぬとは限らんのだが…
https://reboooot.net/post/kernel-params-related-to-oom-killer/
2021/01/05(火) 19:39:22.64ID:eT+iPfAP0
確保しようとしてエラーになったなら対処のしようもあるが、空手形乱発していざとなったら
関係ないプロセスが殺されるってのも困ったもんだよな。
初期のOSXはOOM Killerのような仕組みもなくてシステム全体が固まってたな。
2021/01/05(火) 19:58:11.78ID:dzUtU5Ds0
>>431
1秒後に再度確保？
バカ丸出し
2021/01/05(火) 20:01:22.72ID:8cFKE+AV0
お行儀よく死ぬ機構があるかどうか
2021/01/05(火) 21:50:05.77ID:9HicEvTUd
>>428
話が変わってるぞw
論理的に思考できない根本的にプログラマー向きじゃない人だな
>>429
どんな適切なエラー処理をすればいいのか
ご教示願いたいw
2021/01/05(火) 22:27:33.74ID:K71kt7oj0
>>436
> どんな適切なエラー処理をすればいいのか
ケースバイケース
前提示さずにこんな質問する奴はプログラマーに向いてない
2021/01/05(火) 23:58:57.29ID:zD1ciQHW0
OOM Killer は、Kubernetes のリソース制限の基本。
Linux のnamespace, cgroup

例外は、
アプリ例外は業務上のエラーだから、アプリで処理すべき。
システム障害などは、アプリで処理できる例外ではない
2021/01/06(水) 00:01:25.01ID:WT+BV7/+0
その分類上、メモリ確保失敗はアプリで処理すべきなのかどうかわかんなくない？
2021/01/06(水) 00:46:50.28ID:g4fxgipO0
mallocに失敗したらローカルで確保してみる
それが駄目なら一時ファイル作ってそこに格納する
他にも手はありそうだ
2021/01/06(水) 01:23:26.66ID:8o6ePSWp0
>>440
ねーよ間抜け
2021/01/06(水) 03:55:31.45ID:Sqdcyjlhd
>>437
ケースバイケース言いたいだけだったのかw
>>428
new使うだけでmallocされるのにそんな化石みたいなこと言われても
2021/01/06(水) 05:25:17.33ID:kVhO/tYW0
>>440
> mallocに失敗したらローカルで確保してみる
ローカルが何を意味してるのかわからんがローカル変数のことならはじめからローカル変数で確保しておくべき
2021/01/06(水) 05:28:43.74ID:kVhO/tYW0
>>442
> ケースバイケース言いたいだけだったのかw
言いたいだけって言うかそれ以外に言いようがないだろw
マジで言ってるならプログラマー失格レベル
445デフォルトの名無しさん (ｱｳｱｳｸｰ MMb1-Unlw)
垢版 |
2021/01/06(水) 07:24:13.29ID:bGGeDo6wM
アプリケーション開発しかやったことないのでシビアな状況のプログラムってのがよくわかってないけど

通常のプログラムだったらNULLが帰ってきたら終了だろうね

失敗が許されない環境で、もしメモリを使い果たして確保できないような状況の場合は失敗が許されないのにメモリを使い果たすようなプログラム自身を改善した方が良いような
ファイルから必要なデータだけを読み込むようにして使い終わったメモリは開放するとか

メモリを使い果たして無いのに失敗する可能性とかだったら、標準関数の正常な役割が信用できないという事になるのでプログラム言語自体使えなくなるよね
C/C++だけじゃなくて
それならアセンブラで直接書くしか無くなるのでは
この場合だったら「たらーれば」の言いがかりにしか聞こえないけど
2021/01/06(水) 09:52:33.41ID:NVCaEro60
そこんところはホスト環境・開発システムがどこまで保証するかという話になるので、
各環境で十分な保証があるなら使えばいいし、保証がないなら使えないというだけのことでは。

私も実態を知ってるわけじゃないが組み込み開発だったら
実際には保証というか自分たちで検証することも多いと思うが。
2021/01/06(水) 15:10:46.82ID:6EEBy3Y5d
Linux系にはヒープの上限を設定できないの？
よくある入門書にはnewで敵キャラでもエフェクトでも作って動かしましょうみたいなのがよくあるが
それやって消すのを忘れると一日動かしてるとかなりの容量になり突然システムが止まる
懐かしいシングルタスクOSの時代と変わらんw
Win16や32だとローカルヒープは上限があって一杯になってもアプリが止まるだけでシステムは続行できた
2021/01/06(水) 15:49:09.66ID:kVhO/tYW0
>>447
> Win16や32だとローカルヒープは上限があって一杯になってもアプリが止まるだけでシステムは続行できた
それはプロセス単位の制限だろ、man ulimit でググってこい
OOM Killerとかはシステム全体の話な
2021/01/06(水) 16:05:04.01ID:QohpZ5Jnd
>>446
Cスレだから組み込み系が話題の中心だと思ってたが
PCのアプリをCで書くなんて人がいまだにいるの？
2021/01/06(水) 17:27:30.00ID:NVCaEro60
>>449
ロジック部分を C で書くことはもうあまりないかもしれんが、
低レイヤや速度チューニングがなくなるわけではないからなぁ。
コードの総量に C が占める割合は少ないにしても
C が (一部には) 使われているものはまだまだあるんじゃね？
2021/01/06(水) 17:33:29.06ID:QohpZ5Jnd
アプリの速度チューンならC++で良いと思うんだが
なぜC？
2021/01/06(水) 18:33:49.31ID:m3At07SYM
>>447
ulimit -d でできるぽいね
2021/01/06(水) 18:53:37.18ID:kVhO/tYW0
>>449
LinuxのカーネルとかApacheとか未だにC言語は残ってるよ
新規は少なくなっていくだろうけどCOBOLと同様にメンテでは当面使い続けられると思うぞ
2021/01/06(水) 19:00:16.49ID:A7AJXFBH0
カーネルがmallocで失敗？？？
システムごと死ぬだろ
2021/01/06(水) 20:05:41.96ID:6EEBy3Y5d
>>448
だからアホなアプリ一個でシステムが止まるなんて前世紀の話か？と聞いてるんだよね
それともここはシステム関連の話だけか？
mallocの仕組みもしらずにシステムいじろうなんて命知らずの人だねw

>>452
シェルコマンドじゃなくて
このアプリちょっと試してみてよ、と他人に渡した時に行儀よくできるような言語自体のオプションはないものかな
mallopt()が近いみたいだけど英語ドキュメントしかないや
2021/01/06(水) 20:50:30.31ID:kVhO/tYW0
>>455
> だからアホなアプリ一個でシステムが止まるなんて前世紀の話か？と聞いてるんだよね
だから OOM Killer でググってこいよ
システムを止めるかどうかは設定によるし、Windows でもメモリー逼迫したら不安定になるから

> シェルコマンドじゃなくて
https://linuxjm.osdn.jp/html/LDP_man-pages/man2/setrlimit.2.html
そもそもシェルから設定できるのにプログラムから設定できないわけ無いだろ
プログラマーの素養なさ過ぎ
2021/01/06(水) 20:52:54.12ID:3ZsNazx6d
C言語なんだから無条件でPC前提にするのやめようぜ
2021/01/06(水) 20:58:31.92ID:3ZsNazx6d
Windowsでも
プロセスとスレッドのプライオリティを上げて
メモリを大量に使えば
スワップしまくって激重になって
事実上システムが死ぬけどね
2021/01/06(水) 20:59:44.32ID:3ZsNazx6d
アプリ1個でシステムダウンさせるのはそれほど難しくない
2021/01/06(水) 21:09:38.92ID:yUU4KxYw0
>>459
さすがにそれは不可能では？win3.1 ならまだわかるのですが‥‥
2021/01/06(水) 21:12:39.72ID:3ZsNazx6d
プライオリティの高いスレッドをたくさん作って無限ループすれば死ぬ
2021/01/06(水) 21:17:12.89ID:3ZsNazx6d
プライオリティ31のスレッドを論理コア数分作ればマウスカーソルも止まる
2021/01/06(水) 22:06:17.54ID:FKs+KUNY0
間違えてforkしまくるスクリプト実行してしまって何もできなくなった
2021/01/06(水) 22:06:21.76ID:6EEBy3Y5d
いや別に知恵を絞って無理に止める話はしてないじゃんw
うっかりミス程度で止まったらおそろしいなあ気楽にプログラミングもできないなあって話
2021/01/06(水) 22:38:40.29ID:g4fxgipO0
うっかりシステムをフォーマットしてしまうこともあるしな
2021/01/07(木) 00:44:03.16ID:Vx7SD3qO0
うっかりプライオリティの高いスレッドをいっぱい作っちゃった場合の話
2021/01/07(木) 02:16:41.45ID:yeIMGQh50
何の話してたか忘れた
2021/01/07(木) 15:11:57.86ID:9QJGSme00
mallocを使っていても総使用量の最大は見積もっとけって話
2021/01/07(木) 16:20:03.10ID:DL1zbij8d
総使用量に対してメモリが十分あっても
フラグメントで確保出来ないかもしれない
2021/01/07(木) 17:22:12.04ID:6v7F/BUW0
malloc をラップして
オレオレアローケーターで一括で確保して使いまわそうとすると
malloc の実装とほとんど変わらんよな？って気分になる
2021/01/07(木) 17:32:32.97ID:DL1zbij8d
固定長が多ければ専用化の価値が大きい
2021/01/07(木) 17:50:56.57ID:9QJGSme00
>>469
malloc実装してみな
フラグメントなんてどんな程度の問題かわかるから
2021/01/07(木) 19:23:46.37ID:jTCzKEfy0
とあるスコープ内だけで有効なヒープで、さらにスコープから抜けると開放したい
という用途でがんばった
2021/01/07(木) 20:07:04.52ID:b6arBunA0
何十日何百日稼働するソフトならそれなりに効いてきそうだけど＜フラグメント
2021/01/07(木) 20:08:45.38ID:gAnZzjje0
>>473
alloca()
2021/01/07(木) 20:19:01.01ID:jTCzKEfy0
>>475
ほしかったがなかったのだ
2021/01/07(木) 21:26:54.87ID:gAnZzjje0
>>476
C にはデストラクタがないから、C の範囲で実現するのは困難ですね
alloca() の実装は、ライブラリだけでは処理できずにコンパイラ側の支援が必要だと思いますので、標準ライブラリには入りにくいでしょうね
2021/01/07(木) 21:43:59.65ID:jTCzKEfy0
>>477
longjmp は対象外とし
完全自動は諦めてスコープの外に回収関数を置く紳士協定で手打ちに
2021/01/08(金) 00:02:52.02ID:RWydUoCr0
>>472
フラグメントで確保出来ない事があったわけだけど
2021/01/08(金) 00:51:10.08ID:aEO+ezsE0
使ってるアロケータの実装が何なのか, とどう使っているか示さないと何の意味もない
K&R mallocに毛が生えた程度のmalloc (Tronとか)ならものすごい勢いで断片化するし

glibc mallocとかのbest fitアロケータを使う分には断片化はかなり起こりにくい

あとメモリリークじゃないことは間違いないんだよね？
2021/01/08(金) 05:16:18.16ID:gKD5AY0L0
>>479
>>388を再度問う
2021/01/08(金) 08:53:26.45ID:/42fFLGad
C言語スレなのに組み込みやったことないヤツばっかりってのが不思議

>>480
アロケータの実装次第で断片化がおこる
と自分で書いてるわけだ
それが答え

どんな優れたアルゴリズムでも
断片化はおこるんだけど
完全に未来が予測出来る神アルゴリズムでも
2021/01/08(金) 09:11:57.78ID:yPaAOWPid
Go/C/C++以外に直接システムコールしてる言語ってありますか？
2021/01/08(金) 09:18:29.89ID:/42fFLGad
アセンブラ
2021/01/08(金) 09:37:02.14ID:MUX0m4u5M
c/c++もアセンブラ使わないとシステムコール呼べないけどな
2021/01/08(金) 12:03:05.57ID:lqJPJl/10
CALL 5 が使える言語は全部大丈夫
2021/01/08(金) 12:52:43.97ID:0DW9z0rLM
>>486
call 5って何のこと？
2021/01/08(金) 14:24:17.01ID:PuoTeu6a0
>>477
VLA があれば alloca は要らん。
上限が見積もれないときはいずれにしても使うべきではないが……。
2021/01/08(金) 14:34:20.89ID:NkKDsd1u0
CALL 5ってシステムコール一般の事を指してるのかな？

CALL 5はCP/Mから引き継いだMS-DOSのファンクションコールか
ふつうMS-DOSはINT 21Hって内部割り込みつかってたけどCALL 5もできたそうな
2021/01/08(金) 15:15:28.39ID:/42fFLGad
直接システムコール
の定義によってはどの言語でも出来るし
定義によってはどの言語でも出来ない

質問者は定義を明確に
2021/01/08(金) 19:43:55.15ID:cUApPko30
>>488
でも VLA は C++ では非推奨でしょう？
というか C であっても VLA の格納位置がスタックなら、それこそ悪意を持つクラッカに格好の餌をやっているとしか思えません‥

C99 or later では「VLA の確保場所をスタック禁止でヒープとする」という縛りはあるのでしょうか？
2021/01/08(金) 21:47:27.82ID:cUApPko30
>>491,448,477
いろいろ調べたところ、私が間違っていることがわかりました、つまり alloca() はスタックに配列を確保する実装とのことだそうです
つまり alloca() は setjmp/longjmp と同じ「C で記述できない」関数ということになりますね‥‥
2021/01/08(金) 22:26:35.55ID:gKD5AY0L0
だからこそ標準に組み入れられているんだよ
非標準でどうしろと言うのか考えろ
2021/01/09(土) 13:37:23.88ID:lvRTpcj70
アセンブラで作ったサブルーチンをそうとは知らずに呼べるのはCの良いところ
2021/01/09(土) 14:13:13.77ID:wanRtpand
それだけならC++でも
2021/01/09(土) 16:16:23.92ID:fHVxD+CU0
知らずに呼べるって、それアセンブラ側でC呼び出し規約で書いてあげたからじゃね。
2021/01/09(土) 16:42:31.78ID:lvRTpcj70
ABIちゅーもんがあってだな
2021/01/09(土) 17:00:45.39ID:fHVxD+CU0
だからそう言ってる。Pascal規約で書けばPascalから呼べたり。
2021/01/09(土) 17:08:25.76ID:L3ZBilIB0
フルアセンブラなら
パラメーターの渡し方は自由

独自のスタック構造だろうが
レジスタだろうが
臨機応変に出来る

今時フルアセンブラなんて事は非常に稀で
C/C++の呼び出し規約に従うのが普通
というだけ
2021/01/09(土) 17:10:33.54ID:L3ZBilIB0
今でも超小規模マイコンだと関数コールの構造をとらないフルアセンブラコードを使う事がある
2021/01/09(土) 17:52:11.58ID:lvRTpcj70
__declspec(naked)とか__attribute__((naked))とか
2021/01/09(土) 18:48:02.08ID:fHVxD+CU0
それexternで宣言できないから、アセンブラで書いたルーチンを呼ぶためのものじゃなくて
従来アセンブラを使わないと書けなかったルーチンをCのインラインアセンブラで書くためのものじゃね？
503デフォルトの名無しさん (ﾜｯﾁｮｲ 7f40-Cbw0)
垢版 |
2021/01/09(土) 19:47:19.13ID:gjIQ6YZR0
純粋なC言語プロジェクトとして作るより
C++プロジェクトとして作ってCコードを書いた方が
利用可能なライブラリが増えるしほぼ上位互換、という考えは合ってる？
2021/01/09(土) 19:51:04.00ID:Z+DmrKyh0
>>503
それ多分C++コードだと思う
2021/01/09(土) 20:16:57.05ID:kPw1IBO30
>>494
それができない言語の方が珍しいと思うけど？
2021/01/09(土) 20:17:11.62ID:OS8QkCVT0
C++のベターC的な使い方であってpureなCとうまく連結できるかというと…
2021/01/09(土) 20:18:36.46ID:kPw1IBO30
>>503
合ってる、いわゆるベターCって奴
2021/01/09(土) 21:18:21.63ID:lvRTpcj70
DLLなんかどこの馬の骨言語／コンパイラ／アセンブラで作られたかもわからんものを当たり前に使えるだろ
2021/01/09(土) 22:58:21.36ID:L3ZBilIB0
それはDLLで呼べるように作ってあるからであって
2021/01/09(土) 23:00:18.51ID:L3ZBilIB0
別にCの特徴でもない
2021/01/09(土) 23:45:25.11ID:kPw1IBO30
大抵の言語はDLLを呼び出す側になれるけど、呼ばれる側になれる言語はそんなにない
2021/01/09(土) 23:52:15.63ID:lvRTpcj70
普通にCでDLL書くぞ
513デフォルトの名無しさん (ﾜｯﾁｮｲ ff8c-Ip2P)
垢版 |
2021/01/10(日) 16:59:27.49ID:97ZwT7Zl0
言語はOSに依存している。
2021/01/10(日) 17:02:58.26ID:N5z3vzVP0
OSのない非常にチープな環境でも動くのがCの特徴
例えばRAM 16バイト、ROM 256命令みたいな糞CPUでも動く

リッチな環境ならCなんか使わん
2021/01/10(日) 17:07:41.53ID:rshCbxDT0
>>514
> 例えばRAM 16バイト、ROM 256命令みたいな糞CPUでも動く
具体例plz.
2021/01/10(日) 17:12:34.41ID:N5z3vzVP0
PIC10F200
2021/01/10(日) 17:29:30.48ID:rshCbxDT0
>>516
ありがと、一応コンパイラもあるのね
2021/01/11(月) 04:19:33.81ID:aEPvAJq60
そんくらいならCよりアセンブラの方が楽そうだけど
2021/01/11(月) 09:26:06.49ID:yw8V+8is0
この規模でもアセンブラの方が楽って事はない
当然性能やリソースに問題がないならCの方が楽

楽をしたいなんて考える人が選ぶCPUではないけど
2021/01/11(月) 09:57:05.78ID:MiJ5pxpq0
PIC は CPU なのか？
と思ってデータシートを見たら RISC CPU って書いてあったわ。
2021/01/11(月) 10:16:28.83ID:RSMcM3e30
>>518
まあさすがにROM 256だとCで書くのはあまり現実的じゃないわな
2021/01/11(月) 10:28:09.66ID:dLrb5ZQk0
>>519
コンパイラが相当なじゃじゃ馬だと
調教する（というか、こっちがされるｗ）のに
結構な手間暇かかったりするんだよ
2021/01/11(月) 12:12:48.66ID:yw8V+8is0
>>522
PIC(というか8bit全般)は
命令やアーキテクチャがじゃじゃ馬
Cのじゃじゃ馬とは比べ物にならん

開発環境構築はCもアセンブラもかわらん
2021/01/11(月) 12:23:14.39ID:dLrb5ZQk0
Cのじゃじゃ馬を調教するにも結局アセンブラを理解する必要があるからな
アセンブラのじゃじゃ馬だけで済むならそっちの方が楽だろ
2021/01/11(月) 12:30:40.51ID:4UZaL5drd
アセンブラを理解する必要なんて無いよ
2021/01/11(月) 12:34:47.00ID:dLrb5ZQk0
あるよ
Cに対するよくある誤解で、
アセンブラから逃げるためのものではなく
アセンブラもわかる人が手抜きするためのものだ

そもそもアセンブラで書かれていたUnicsを書き直すために作られたツールだしな
2021/01/11(月) 12:37:16.69ID:4UZaL5drd
>>526
いつの時代の人？
2021/01/11(月) 12:37:56.75ID:4UZaL5drd
楽かどうか
から話が変わってるし
2021/01/11(月) 12:54:40.32ID:RSMcM3e30
256程度に収まるコードならアセンブラでもそんなに苦労しないと思うよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況