C言語なら俺に聞け 156

2020/09/28(月) 14:41:30.00

!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

2021/01/25(月) 00:11:52.23

オーバーブッキングを平気でするホテルみたいだな

2021/01/25(月) 01:00:15.57

>>641
バカ？

2021/01/25(月) 01:17:43.98

iOSのreusableCellの取得も必ず成功するからforce unwrapできるし

2021/01/25(月) 07:05:04.38

>>641
仮想アドレスを使わないOSもあるんだが
まあ安易に「全て」とか使ってるからレス乞食なんだろうな

2021/01/25(月) 08:02:50.43

>>641
勉強しろと言った本人が理解していないのが丸わかり。
使う時まで要らないのは物理メモリであってmallocの時点で仮想アドレスは割り当てなきゃならん。
もし仮想アドレスに空きがなけりゃ「とりあえず割り当てる」なんてのも無理。

2021/01/25(月) 09:02:02.61

実際「mallocは常に成功する」とか根拠なく信じ込んでる奴にはシステム開発は任せられんよ
あとで痛い目みる

2021/01/25(月) 10:01:03.33

>mallocは常に成功する
Win98SEで失敗したしたことあるわ。

2021/01/25(月) 10:44:35.68

　ハードがMMUで物理的に管理するメモリ上限とか、OSが管理する上限とか、論理上いつか確保出来ない状況は絶対来るの分かっているけれど、そこでエラー起こされると打つ手がない(思い付かない)から、そのまま落ちてもらう。
　俺が知らないだけで、良い回避方法とかあるのかな？

2021/01/25(月) 11:32:21.69

>>649
・オーバーコミット機能はオフにする
・ malloc (等) がエラーを返すかチェックを怠らない
・終了処理にどうしても必要なメモリは事前に確保しておいて他に使わない

2021/01/26(火) 07:53:24.98

非常用のメモリを取っとくのは
大昔から当たり前の手法だね

2021/01/26(火) 09:07:24.49

mallocを信じて生きていけばいいさと　君は叫んだだろう

2021/01/26(火) 10:29:56.18

>>652
https://www.youtube.com/watch?v=dAs2yQUNkdU

2021/01/26(火) 11:06:15.63

メモリ不足だと表示して終了しちゃいかんのか？

2021/01/26(火) 11:51:32.15

>>654
それでいい状況ならそれでいいんだよ。
それじゃ駄目なときの話をしてる。

2021/01/26(火) 12:18:24.13

車を運転してたら
「メモリ不足です」と表示されてブレーキが効かなくなった

冷蔵庫が「メモリ不足です」と表示されて止まっていた

ああメモリ不足ならしょうがない
って思う人いるかな？

2021/01/26(火) 12:24:58.20

航空機搭載システムなんかは動的メモリ割り当て自体を禁止してるそうな
でもアルゴリズムによっては動的メモリ割り当てが本質的なこともあるだろうし
事前割り当てしたところで、自前でmymallocを実装するってだけな気はするし
ミッションクリティカルなアプリがどうやってるかはちゃんと調べないと判らんね

2021/01/26(火) 12:29:47.88

航空機なんて特別な例を出さなくても
身の回りの電気製品でソフト要因のエラーが許される物なんてなかなか無いような気がする

2021/01/26(火) 12:41:48.87

>>657
オーバーフローは危険なのでスタックの使用も禁止します

2021/01/26(火) 12:49:59.07

条件を満たせは静的解析でスタック使用量はわかる
整数型はオーバーフローして危険だから禁止

2021/01/26(火) 13:32:22.24

そういえば何の事例だったかでループも禁止 (停止性の証明が難しいので) とかいうのは聞いたことがあるな。

2021/01/26(火) 13:33:43.60

>>659
再帰禁止とか組み込みなら珍しくないぞ

2021/01/26(火) 14:31:35.84

>>661
ループ禁止でコードを組める気がしないのだが
処理したらCPUリセットするの？

ループ以外に何か禁止な条件があるはず

2021/01/26(火) 14:35:21.22

ヒープ禁止は普通にある
禁止というかそもそもヒープ用にメモリが無いとか
設計方針でヒープモジュールを搭載しないとか
あとは確保オンリーなヒープってのもある

PICとかだとハード的に再帰が難しいとか

2021/01/26(火) 21:31:25.38

JALの航空管制制御のプログラム作ったことあるけど、
1ルーチンコードサイズ4KBまでIBM3090アセンブラ
ループ処理などなく、また呼ばれる
可愛い平さん元気かなぁ・・

2021/01/26(火) 21:32:25.57

手塚さんとかも綺麗だったな・・おれまだ学生だったw

◆QZaw55cn4c (ﾜｯﾁｮｲ bfe9-pMYN) · 2021/01/26(火) 23:53:23.00

>>653
コード進行が凄い曲ですね‥‥ギターコードが書いている楽譜ってないですかね？

2021/01/27(水) 00:01:47.99

上の空で書いていたのか

2021/01/27(水) 07:49:16.31

8/16bit時代のハードみたいに起動時にメモリサイズやエラーチェックしてワークエリアサイズ固定で設計するだけだわな。
そういやぁある記事で80286って工業用途を想定してて、エラーが発生して停止したら電源入れ直す以外に再起動できないとか言ってたな。

2021/01/27(水) 07:52:13.49

>>665
ルーチンの呼び元はループ、もしくはループ相当の動きをしてるわけだよね

ループがなければ無限のサイズのコードじゃ無い限り動き続けるのは不可能じゃ？

2021/01/27(水) 07:59:19.27

>>667
非常に簡単なのしか使ってないんで耳コピ簡単じゃ？

2021/01/27(水) 10:55:52.75

>656
>「メモリ不足です」と表示されてブレーキが効かなくなった
上級国民が大喜びな仕様だな。

メモリ不足になるような仕様を避けるのが当然で、
それでも起きるなら安全に停止できる機能を搭載するだろ。
とりあえず電源喪失状態でもブレーき利くようにするとか。

そういやぁどっかの列車で安全装置の故障で自動停車されなくて事故ったってのあって、
安全装置からの信号がONになった時にブレーキが作動するって仕様になってたのを
安全装置からの信号が来なくなったら（ずっと信号ONって不具合もかあるだろうから通信のやり取りでもあるのかな）
ブレーキ作動させるようになったって聞いたわ。

2021/01/27(水) 11:34:46.40

>>667
Monacaの田中秀和って好き？

2021/01/27(水) 12:05:51.10

>>656
飯塚会長なら言いそうだ

2021/01/27(水) 12:09:55.82

>>662
組み込みが再帰禁止なのは
スタック段数が少な過ぎるからじゃないんですか
>>659 と同じことを言ってるだけと思いますが

2021/01/27(水) 12:12:51.81

>>663
常にHALT＋割り込みのみで書かれたものはあったはず

2021/01/27(水) 12:27:46.11

>>675
その理由もあるけどスタックの見積がやりにくいからという理由もある
>>661に類似だけど停止条件トチッたら容易にスタック食いつぶすし

**デフォルトの名無しさん** (ｽﾌｯ Sd7f-n4Sq) · 2021/01/27(水) 13:33:58.28

>>662
貧乏マイコンは数段程度しかないから関数の中で関数呼ぶのすら危うかったりするな…
高級マイコンは16段の見たことあるが

2021/01/27(水) 13:57:29.31

HALTと割り込みでもいつかはどこかで最初からの繰り返しループにならない？
割り込み中でステート管理して、スタックを操作して最初に戻るとか？
出来ないマイコンもありそうだけど

2021/01/27(水) 14:01:16.93

そういう制御込みでコンパイルして吐き出してくれるなら Cの選択肢もあるだろうけど
それが期待できないとなると　アセンブラしかない　ってことになるのかな

2021/01/27(水) 17:35:31.51

>>678
PICでしょ
一番安いヤツはハードウェアスタック2段

2021/01/27(水) 17:36:57.11

>>679
手段は色々あっても
ループはループ
と思う

2021/01/27(水) 20:45:42.53

>>679
まあどこかでループは必要だわな
>>661はそういうループはきっちり検証して個々の処理ルーチンではループ禁止っていう話かと

2021/01/27(水) 23:07:06.58

初心者です
変数に&を付けてメモリのアドレスを表示させるプログラムを実行して(0x7efe61e298d8←こんな感じ？)
その後1時間とか経過して別のプログラムでメモリ「0x7efe61e298d8」に格納されたものを表示させることってできるんですかね？

2021/01/27(水) 23:11:59.94

OSが何かにもよるけど
一般論としては出来る。出来るが、
成功するかどうかは分からない

2021/01/27(水) 23:34:48.42

MS-DOSのTSRか

2021/01/27(水) 23:52:57.86

C言語というよりOS側の問題なんですね
ありがとうございます

2021/01/28(木) 05:11:34.57

>>681
それ、スタックを使って構造化プログラミングを実現した言語であるCを使う利点が一切ないような…

組み込み/マイコン向け言語でスタックを使わず構造化プログラミングを実現するにはcpsスタイルの言語がベストなはず、lisp方言schemeにはそれ向けのサブセット仕様もあるし、ホビー界隈ではそこそこ使われてる模様
（但し主なpc向け実装は、アーキテクチャに合ったスタックによるcps実装が多い、念のため）

forthも消えてしまったなあ
C換算百行未満でブートストラップ&セルフホスト処理系が書け、OS機能も兼ね、規格にあるライブラリ関数も改変無しコピペで動く移植性の良さ
c台頭までは組み込み/マイコン界隈を寡占してたんだが
ちゃんとスタック指向&構造化言語だけど、ハードウェアスタックに頼らないので相性がよい
唯一の敗因はlisp以上に深淵なことだな…

cは既に国際語になってしまったので、取り敢えず分かるcで書く、ってのがcが使われる唯一の理由だと思う

2021/01/28(木) 05:58:13.87

動的確保なしの３２ビットマイコン使って飯食ってるけど、さすがに再起は使わんが、
好きなだけ関数呼び出し深く出来るだけでも恵まれてたんだな。スタックオーバーフローは一応気にしないといかんけど。

ミッションクリティカルなコードなんてゼッテー無理だわｗ Adaとか使われるんだっけ？と思ったら微妙に廃れ気味なんね。よーしらんけど。

2021/01/28(木) 08:01:19.64

>>684
たぶん意味がない。
今時のOSでは、別々のプログラムからメモリ「0x7efe61e298d8」を参照しても同じ内容にならない。「仮想アドレス」でぐぐれ。
プログラム間で変数をやりとりしたければ、共有メモリを使う方法がある。

2021/01/28(木) 08:05:06.42

今時のOS,CPUだとアクセスした瞬間に例外発生する

2021/01/28(木) 10:46:55.99

>>684
(現代的なコンピュータアーキテクチャでは) 各プロセスのアドレス空間が独立していて、
あるプロセスから見えているメモリの内容と他のプロセスから見えるそれは別物なんだよ。
他のプロセス (が持っているリソース) にアクセスしたりデバイスをコントロールするには
OS に依頼して仲介してもらうという形をとる。

プロセス間でメモリの共有をすることも可能だが、
それもあらかじめ OS に伝えて共有する実体 (物理メモリ) をそれぞれのメモリ空間にマッピングしてもらう形
なので、それを利用するプロセス同士が事前に共有に同意した状態である必要がある。

あるプロセスが自分用に割り当てられたリソース以外にはそう自由にはアクセスできないんだ。
それがセキュリティというものだよ。

2021/01/28(木) 11:01:24.92

>>682
毎回リセットして最初から実行するのも君の説ではループの範疇だな

2021/01/28(木) 11:03:43.19

>>690
>>692
DLL injection とかしても無理？

2021/01/28(木) 11:57:56.44

>>694
アクセスされる側にとって (普通は) 意図しないものであるには違いないけど、
一応は OS が許可した上で各プロセスにアタッチする形なので
ひとつのプロセス内でのことになるから別のプロセスからアクセスするのとは理屈が違うんじゃないかな。

プロセスの独立性は壊れないし、権限が上位のプロセスにはアタッチできないんじゃなかったっけ？
まあときどき権限昇格の脆弱性が発見されたりはしてるけど……。

2021/01/28(木) 12:14:49.58

>>684
デバッガでも作りたいのか？

2021/01/28(木) 12:16:47.81

>>693
そうだね
ソフトによるリセットなら本質的にはソフトループと変わらない

◆QZaw55cn4c (ﾜｯﾁｮｲ bfe9-pMYN) · 2021/01/28(木) 19:47:55.90

>>671
クラシック系の耳にはすごく斬新に聞こえますが、世間一般的には簡単な部類に入るのですか、私は井戸の底の蛙だったんですね‥‥

◆QZaw55cn4c (ﾜｯﾁｮｲ bfe9-pMYN) · 2021/01/28(木) 19:50:41.53

>>686
TSR はロマンで私もキー入れ替えとかいろいろ凝っていた時期があったんたけど、TSR に似たプログラミングって最近はなんですか？

◆QZaw55cn4c (ﾜｯﾁｮｲ bfe9-pMYN) · 2021/01/28(木) 19:51:53.47

>>692
でも、i386 アーキテクチャの「コールゲート」とかは廃れてしまったんですよね…‥

2021/01/28(木) 20:19:09.21

WaveToneとかの便利なソフトがあっての

◆QZaw55cn4c (ﾜｯﾁｮｲ bfe9-pMYN) · 2021/01/28(木) 22:08:52.27

>>701
そのソフトは大昔(win95 の時代）にも開発してくださっていた方がいて便利に浸かっていました‥‥
----------------------------------------------------------------------------
【ソフト名】 TonagramView for Win95 Ver.0.3β
【作成者】 Zephyr <NCC00723@niftyserve.or.jp>
【登録名】　SHIINE03.LZH
【圧縮形式】　LHa 2.55b
【動作環境】　Windows 95
【転　　載】　事前の許可が必要
【掲載月日】　1997/08/30
----------------------------------------------------------------------------

このプログラムは、WAVファイルを周波数解析してtonagram(ピアノロールのような
グラフ)を表示するツールです。

耳コピをしていると、どうしてもコードが採れなくて泣きたくなることがよくあり
ます。そんなときは、tonagramを調べれば、鳴ってる音を目で見ることができるの
で、適当にピックアップしてやれば楽にコードを拾えます。v(^^)

今回、GUI化によりリードアウトカーソルなどの機能が強化されています。
また、解析結果のロード・セーブが可能になりましたので、結果をセーブしておけ
ば解析にかかる時間を節約することができます。

★Ver.0.2βからの改良点
・待望(?)のGUI化
　　ロード・セーブ・印刷
　　リードアウトカーソル　等
・ピークサーチアルゴリズムの変更(精度より見た目を重視)

NCC00723 Zephyr

2021/01/29(金) 00:08:49.78

>>698
斬新に聞こえるかどうかはともかく
コード自体は非常に簡単

ちなみに私もクラシック系

2021/01/30(土) 12:01:56.26

>>702
404

2021/01/31(日) 19:33:07.61

enum A
{
max_value = 0x7fffffffffffffffLL;
};

こんなことしても64bitのenumはつくれないんだっけ？

2021/02/01(月) 00:52:02.23

整数型ならいいらしいから、64bitになるコンパイラがあっても規格違反ではないと思う

2021/02/01(月) 01:29:58.21

infinity 定義されてるだろ？

2021/02/01(月) 07:03:50.51

整数型に？

2021/02/01(月) 07:51:42.98

>>706
処理系依存しないで確実に64bit以上にする方法ってないんだっけ。
ベース型の指定はC++だよなあ。

2021/02/01(月) 08:04:18.96

64bit整数型がない環境があるんだから
確実に64bit以上なんて無理

2021/02/01(月) 08:15:50.49

sizeof max_value
gcc, clang: 8
cl: 4

2021/02/01(月) 08:27:26.16

>>710
じゃあ「64bit整数が使える環境で」って条件だとどうだろう？

2021/02/01(月) 09:03:50.04

Cのenumはマクロと大して変わらんのだから、マクロで代用するとか

2021/02/01(月) 09:11:58.71

マクロに代わるべく作られたenumがマクロで代用されるとは
無様な・・・

2021/02/01(月) 09:18:04.19

6.7.2.2 Enumeration specifiers
3 The identifiers in an enumerator list are declared as constants that have type int and may appear wherever such are permitted.

6.7.2.2 列挙型指定子
意味規則　列挙子並びの中の識別子は，型int をもつ定数として宣言され，この型の定数が許されるところならばどこに現れてもよい。

はっきり、intと書いてあるね
long longになる余地は全くない

2021/02/01(月) 11:57:56.06

intとlong longが同一の可能性は残る
まぁ普通ではないが

素直にC++でenum classにするのがいいのでは

2021/02/01(月) 14:28:14.54

enum と enum class って紛らわしいよね

2021/02/01(月) 17:41:32.38

enum classは関係ない
enum-baseだ

2021/02/01(月) 19:37:32.66

>>718
enumのベース型ってenum classじゃなくても出来たのか
勘違いしてたわ

2021/02/01(月) 21:43:21.53

>>715
なるほど、ありがとう。

2021/02/02(火) 06:19:12.09

enumはステート制御で重宝する。

2021/02/02(火) 15:29:55.49

質問です。__lsan_disableが期待通りに動きません。
サイト見るとAllocations made between calls to __lsan_disable() and __lsan_enable() will
be treated as non-leaks. Disable/enable pairs may be nested.と書いてあったのでプログラム作りました。
しかし__lsan_enable～__lsan_do_leak_checkもリークチェックされます。原因が分かりません。

#include </usr/lib/gcc/x86_64-linux-gnu/10/include/sanitizer/lsan_interface.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void* thFunc(void *arg) { __lsan_disable(); sleep(4); fprintf(stderr, "en start\n"); __lsan_enable();
fprintf(stderr, "en end\n"); sleep(4); __lsan_do_leak_check(); exit(-1);
}
int main() { int rc; pthread_t th; pthread_create(&th, 0, thFunc, 0);
for (int i = 0; i < 30000; i++) { sleep(1); int *p = malloc(1);
fprintf(stderr, "malloc\n"); } return 0;}
よろしくお願いいたします

2021/02/03(水) 08:08:40.40

>>712
処理系依存

2021/02/04(木) 11:24:59.43

テキストファイルを読み込む場合、主にfgetsやfgetcでやる方法があると思うのですが調べてみるとmmapを使う方法もあるようなのですがどれを使うのが良いんですかね？
やりたいのはhtmlソースの書かれたテキストファイルの簡単な解析です
もしくは全く別に有名なライブラリみたいなのがあるんでしょうか？

2021/02/04(木) 12:15:35.04

>>724
大きなファイルに細かなランダムアクセスが発生するときは
シークを繰り返すよりも mmap を活用した方が有利になることもあると思うけど、
常識的に考えればひとつの html はせいぜいが数メガ程度だろうし、
凝った管理をしなくても全部メモリに乗るでしょ。

2021/02/04(木) 13:31:56.12

>>725
ファイルサイズで使い分ける感じなんですね
ありがとうございます

2021/02/04(木) 13:43:25.23

>>726
処理の内容によってプログラムのデザインには選択肢があって、
ファイルからの読み込みの仕方はそのデザインに付随するという感じ。

2021/02/04(木) 14:20:09.93

C言語スレで
せいぜい数メガと言っちゃう感覚

2021/02/04(木) 14:24:26.67

もう21世紀だからな
ここから先は1GBのテキストファイルが普通になる

2021/02/05(金) 07:55:44.29

>>728
テキストファイルを読めてhtmlをパースするような機器で今どき数メガも載ってないケースってかなり珍しいだろ

2021/02/05(金) 08:01:49.33

せいぜい数メガと言えるようなリッチな環境で
C言語でアプリを書く方が珍しいだろ

2021/02/05(金) 08:20:44.95

>>731
質問者>>724がやりたいって言ってるんだから、珍しいかどうかなんてどうでもいいだろう

2021/02/05(金) 08:32:27.83

せいぜい数メガと言えるようにリッチな環境かどうかなんて
>>724にしかわからないわけだけど

で>>731を考えたらリッチじゃないって考えるのは自然な発想

2021/02/05(金) 08:42:07.98

「決めつけ」はバグとセキュリティホールの元。

2021/02/05(金) 09:02:30.99

スパコンのOSはCで書かれている

2021/02/05(金) 09:20:14.53

>>731,733
なぜC言語なのかは>>724に聞いてくれ
少なくとも今どきmmapまで使える環境でメガも乗ってない環境って相当珍しいだろって話な

2021/02/05(金) 12:39:42.10

>>736
>>734

2021/02/05(金) 12:52:09.08

>>737
珍しくないと言うなら実例をあげればいいだけ

2021/02/06(土) 10:12:48.76

mmapってUNIX系OSだけでは？他にもあるかも知れないが互換ライブラリ経由でそのOS固有の同機能のやつ呼んでたりしない？(それで良いなら良いんだが)

2021/02/06(土) 10:51:00.80

対象をhtmlに限定したのが敗因

2021/02/06(土) 11:26:44.70

>>739
メモリマップトファイル一般を指しての発言じゃないかな、CreateFileMapping()とか含めて。

>>740
たぶんシーケンシャルアクセスで足りるから、read()でええやんってなるよな。