C言語なら俺に聞け 153

2019/08/17(土) 23:02:42.00

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/
-
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
※前スレ
C言語なら俺に聞け 152
https://mevius.5ch.net/test/read.cgi/tech/1560763630/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

**798** (ﾜｯﾁｮｲ ae2c-fJ/L) · 2019/12/27(金) 21:01:30.94

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006

この研究会は、トヨタなど大企業から、数十人のベテが集まって、
欧州人に聞きながら、作った本。
未だに、コーディングルールのバイブルだろ

元々は、Andrew Koenig の本

C Traps and Pitfalls, 1988, c1989
Cプログラミングの落とし穴

この本から、Lint が始まったのじゃないか？

2019/12/27(金) 21:11:55.30

>>818
別に他のところに興味ないし
まあこんな初歩的なところに突っ込まれるとそりゃ困るわなw
だからROMってりゃいいと思うんだけどな

2019/12/27(金) 21:13:58.37

>>819
> この本から、Lint が始まったのじゃないか？
流石にもう少し時代を見てからレスした方がいいぞ…

2019/12/27(金) 21:29:02.92

そっかー組み込み屋さんはUNIXの歴史とか知らなかったりするのか

◆QZaw55cn4c (ﾜｯﾁｮｲ ea47-7AkR) · 2019/12/27(金) 21:33:22.44

>>819
＞この本から、Lint が始まったのじゃないか？

違います
初期の lint はベル研の V7 と同時、1979 にはリリースされています
K&R1 は特に引数まわりはスキのある仕様でしたので細かくチェックをいれる lint は必要であったのも理解できます、これは K&R2 になってかなり改善されました
それに最近のコンパイラは lint に似た warning も出せるようになったし

**798** (ﾜｯﾁｮｲ ae2c-fJ/L) · 2019/12/27(金) 22:09:21.87

はじめてのOSコードリーディング UNIX V6で学ぶカーネルのしくみ、青柳隆宏、2013

そう言えば昔、こういう本も読んだ

2019/12/28(土) 01:02:34.32

ジャンケンのコードを書いてみました
よろしければ、ご指摘等をお願いします
https://pastebin.com/HCLJ5m7p

2019/12/28(土) 02:00:59.65

>>825
少しは取り繕えよ
何かのコピペだろ

2019/12/28(土) 06:31:05.78

>>823
> それに最近のコンパイラは lint に似た warning も出せるようになったし
初期のlint使ったことないだろw

2019/12/28(土) 07:57:54.17

>>817
そんな可能性は絶対の絶対にゼロだ

2019/12/28(土) 08:04:30.24

>>815
俺に言わせれば、おまえ文系くせえんだよ
俺はハード設計もやるから負論理だのド・モルガンだのは息をするくらい当たり前なことで
待遇だの裏だのという用語で得意がるやつは専門分野は何だろうと思ってしまうのさ

それから突っ込まれてるのはおまえだぞ、741本人よ

2019/12/28(土) 08:18:01.34

待遇で得意がるvsドモルガンで得意がる
小学生同士かよ

2019/12/28(土) 08:39:28.74

>>829
対偶の話に負論理とかド・モルガン？
恥の上塗りか？
あと741に突っ込んでるのは頓珍漢なお前だけだぞw

2019/12/28(土) 09:32:59.76

やっぱり通じねえなｗ

2019/12/28(土) 09:45:41.04

C言語の話しようぜ

2019/12/28(土) 10:06:23.41

printf("やっぱり通じねえなｗ\n");

**798** (ﾜｯﾁｮｲ ae2c-fJ/L) · 2019/12/28(土) 11:10:17.46

電子回路・HDL などの組み込みでは、
AND, OR, NOT, NAND,NOR などの回路、
負論理、ド・モルガン、カルノー図とか、初歩だぞw

まず、情報処理の組み込みの教科書を読め！

2019/12/28(土) 11:11:43.15

>>831
負論理とかドモルガン知ってる人が対偶の意味知らないと思ってるの？

2019/12/28(土) 11:18:29.36

双対は知らないだろう？

2019/12/28(土) 11:34:08.50

このスレっていつも下らない喧嘩を延々と続けてる奴らがいるけど、何なんだろう。どっちが正しいとか以前に言ってる中身(議論の仕方)が下らなくて他人からはどっちもバカにしか見えないから消えてくれないか。

◆QZaw55cn4c (ﾜｯﾁｮｲ ea47-7AkR) · 2019/12/28(土) 11:34:44.58

>>827
Sun OS 4.1 のはやったことがありますが、初期の頃とは変わっていたのかも

2019/12/28(土) 11:54:34.25

>>836
彼は分かってない
2回も指摘されてるのに論理が破綻していることに気付いてない
>>747,750,751,752
>>782,784,786

2019/12/28(土) 12:53:03.04

>>836
さあどうだろうね、「ド・モルガンの定理知ってる」なら「待遇を理解してる」という命題が証明されたとか聞いたことないし
そもそもド・モルガン知ってるとか言うのも>>829が言ってるだけだし、>>747が対偶でない事を知ってるのかすら怪しいしなw

2019/12/28(土) 13:01:09.99

読んでないから知らんけどこんな雑談に対偶ガーとか論理ガーとか証明ガーってのは馬鹿馬鹿しいね。

2019/12/28(土) 13:08:05.93

似て非なるもの
ド・モルガン
A ∩ B = ¬(¬A ∪ ¬B)
A ∪ B = ¬(¬A ∩ ¬B)
対偶
A ⇒ B = ¬(¬B ⇒ ¬A)

2019/12/28(土) 13:09:43.37

正直、アスペ馬鹿が下らないことを追求したがってるだけにしか見えない

2019/12/28(土) 13:14:14.77

コピペ改変してから何か変だと思い直してみれば正解はこうだったすまん
対偶
A ⇒ B = ¬B ⇒ ¬A

**825** (ﾜｯﾁｮｲ 5e1d-fJ/L) · 2019/12/28(土) 13:19:13.30

>>826
いえ、typedefの文はスッキリCを参考にしましたが、
あとのアルゴリズムはオリジナルです

こんなところで意見を求めるのは図々しいと分かってはいますが、
何とかお願いします

2019/12/28(土) 14:01:27.13

後出しで負けを実装するとよりじゃんけんぽくなるぞ

2019/12/28(土) 15:05:05.31

C言語のBNFって何種類あるの？
知ってるだけ全部教えて

2019/12/28(土) 15:51:37.71

>>842
うん、俺もそう思うよ
>>747が裏も正しいと思い込んでるバカってだけの話だしw

>>844
何を追求してると思うの？
追求すべき事柄なんて特にないと思うけど

2019/12/28(土) 15:54:09.64

>>848
https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The%20syntax%20of%20C%20in%20Backus-Naur%20form.htm

2019/12/28(土) 15:54:25.66

>>848
ググれ

2019/12/28(土) 17:33:03.88

OKグーグル、CのBNFを教えて

2019/12/28(土) 17:41:03.87

K&Rの付録ページになかったかなかな？

2019/12/28(土) 17:45:59.25

BNFで思い出したが

enum { a } func(void) { return a; }

この文法使い道ないよな

2019/12/29(日) 03:22:40.86

>>714
エイリアスの否定とはいただけない
直値だけの糞コードはゴメンだわ
意味によって0とNULLは書き分けるよ

◆QZaw55cn4c (ﾜｯﾁｮｲ ea47-7AkR) · 2019/12/29(日) 10:41:38.70

>>855
その書き分けに意味はあるのでしょうか？

2019/12/29(日) 10:49:06.87

>>856
お前にとっては意味がない。
俺や俺以外の書き分けたい人には意味がある。
それだけだから気にしなくていいぞ。

2019/12/29(日) 11:39:04.46

やたら長いコードの中で
it = &a;
*a = 0;
it = 0;
a = 0;
とか書かれたら混乱するだろ。
あ、でも屑はハンガリー人なんだっけ？

◆QZaw55cn4c (ﾜｯﾁｮｲ ea47-7AkR) · 2019/12/29(日) 11:58:28.30

>>858
ハンガリアンはやらないです

2019/12/29(日) 22:32:49.20

>>858
混乱するから数値のゼロもdefineしなさい

2019/12/29(日) 23:06:45.98

ハンガリー人は宇宙人だから仕方ないね

2019/12/30(月) 06:33:44.11

>>825,846
自分ならこんな感じで書く、程度のものですが思うけど良かったらどうぞ
https://pastebin.com/idm94WiU

別の機能を追加する必要とか出てきたとき、
ジャンケン自体を関数化してあげたほうがmain()関数内がゴチャゴチャしなくて良いかなと思って書きました。

2019/12/30(月) 08:17:18.73

ゴチャゴチャがjankenに移るだけ

2019/12/30(月) 09:11:36.36

typedef char String[1024];

とtypedefしてるのはたしかどこかの教科書の流儀だったはずだ
最近その話題を見かけた

2019/12/30(月) 12:24:04.93

あいこでの再戦と、もう一回じゃんけんするのは、
目的が違うんだから別ロジックにすべき。

2019/12/30(月) 12:31:51.34

同じ処理を共通化する
今後異なる可能性のある処理をあらかじめ分けておく

いろんな設計思想がある

2019/12/30(月) 17:54:24.59

#define O 0

2019/12/30(月) 23:34:38.97

>>864
配列のtypedefって代入で問題にならんのかな
今のCの仕様追ってないけど昔は構文エラーになるから構造体に入れる必要があった

2019/12/31(火) 00:15:56.34

>>825
これは危険なので普通はやらない。

scanf("%s", nextStr);

2019/12/31(火) 00:24:22.42

1文字入力ならgetc使うかな。

2019/12/31(火) 07:44:51.11

>>868
jmp_bufは配列のtypedefだよ

2020/01/01(水) 00:17:51.96

>>871
そういやそうだね
ローカルに作って環境保存にmemcpyした覚えないから代入できるのか
色々忘れてるわ

2020/01/02(木) 09:27:06.04

ポインタを受け取る関数先頭では必ずnullチェックを行うコーティングルールが有るのですが
malloc失敗したポインタをそのまま渡した時ぐらいしか使い道が思い付きません…

2020/01/02(木) 09:28:21.50

freeしたときに0入れるルールもあるんじゃないのそれ

2020/01/02(木) 09:37:24.05

>>873
杓子定規に適用したら形だけの無駄なチェック処理の典型だね。
上位レイヤとの境界のような意味のあるところだけなら現実的だけども。

2020/01/02(木) 09:53:01.45

仕様としてnullを許可する関数ではチェック不要としているのかあるいは一律に
null渡し禁止としているのかで評価は変わりそうだが。

2020/01/02(木) 10:24:26.88

get_state()みたいな関数があって失敗時はnullを返す。それを知らずに別の関数に戻り値を直接渡してしまったとか、nullが誤って渡されるケースなんていくらでもあると思うが。

873が超天才でそんなミスは絶対ありえないとしても、他人のコードやドキュメントが間違ってる可能性もある

2020/01/02(木) 10:39:04.82

Player*とEnemy*を取るRPGのバトル関数で
どちらかが死んでたらplayer->attack()関数は盛大に失敗する

この時の当該playerは消滅したわけでは無いが
enemyはメモリ上から消えている

ついでにこのattack関数が実は関数ポインタに付けられたプレイヤーのスキルだった場合、
attackがカラッポだと、徒手空拳になるか防御するか何もしないか、何故か敵味方全員が即死していきなりエンディングが始まるかのどれかになる

2020/01/02(木) 11:31:53.70

安全性を取るならいついかなる時もNULLチェックは行うべき

だがそもそもパフォーマンス至上主義だから
Cという太古の言語を危険を冒してまで使っているということを考えると微妙

パフォーマンスが重要でないならCを使っていることからして論外

2020/01/02(木) 11:38:58.14

成否を含んだtupleを渡し実行時に判別、式全体を読み飛ばす粒度の小さい隠れた分岐構文みたいなの有ればいいのにねー
成否要素だけの反転は !!tulpevalue みたいな感じで

c言語の仕事じゃないだろうしそもそもtupleなんて持ってないし
うんこマが技巧駆使してわけわからんコード書くツールになるだけかもしれんし弊害いろいろ思いつくけど

2020/01/02(木) 11:39:55.37

>>878
召喚された悪魔が鼻から出てきて世界滅亡エンドも追加しといて。

2020/01/02(木) 12:33:18.19

>>879
Assertマクロとかでいいだろ
テストとかで引っ掛けるという実利に加えて「nullなんて渡すんじゃねーよボケ」と言うのを表明する意味もあるし

2020/01/02(木) 12:38:16.19

nullに意味を持たせないプログラムなら、
null checkしないと落ちる環境ならする意味ないんじゃね

2020/01/02(木) 14:45:20.78

Release build だと assert 消えるって知らない人意外と多いんですね

2020/01/02(木) 15:06:10.66

>>884
消えるって知ってるからassertにしろっていう意見なんだろう

2020/01/02(木) 15:47:44.05

その意見を完全にスルーしてコメントしてる人がいるよね

2020/01/02(木) 16:46:49.09

>>886
誰のことを言ってるの？

2020/01/02(木) 19:01:18.56

ぬるぽ

2020/01/02(木) 19:06:06.49

がっ！

2020/01/02(木) 19:09:50.49

酷い自演を見た

2020/01/02(木) 19:13:07.31

ジ・エンド！

2020/01/02(木) 19:21:03.30

assertを本番環境に持ち込むべきと
主張する痛いやつが昔いたが
奴は今どうしてるかな

◆QZaw55cn4c (ﾜｯﾁｮｲ 2247-70g7) · 2020/01/02(木) 19:35:59.09

C++11 の static_assert は便利なんですけれどもね…これ、C に入らないかな…
assert も static_assert と同じ用途・考え方で使うべきものかと思いますね

2020/01/02(木) 20:05:40.84

Cにもstatic_assertか
考えたこともなかったが
確かにあったらよさそうだな

もういじるなってのが
俺の基本だが
追加に賛成できる珍しい例だ

2020/01/02(木) 20:45:56.41

>>892
> assertを本番環境に持ち込むべきと
> 主張する痛いやつが昔いたが
> 奴は今どうしてるかな
本番用はいちいちassert外してるのか？w

2020/01/02(木) 20:51:06.32

おいおいおい

2020/01/02(木) 20:59:07.77

>>895
assert は Debug ビルドのときだけチェックを行う実装になってるのが普通

2020/01/02(木) 21:59:00.14

>>897
だから>>892が意味不明なんだけどw

2020/01/02(木) 22:07:28.72

>>898
リリースビルドで有効な assert を用意するだけだろ
何が不思議なの？

2020/01/02(木) 22:08:11.77

本番環境に持ち込むべき
影響出ないんだから
こういうことでは

2020/01/02(木) 22:22:27.18

深いところで拾ったエラーを浅層に戻して対応する必要がなく「ダメよ」と述べ落ち許されるプログラムならば
assert残すのも有りよね
実際#ifdef DEBUGで包んでるだけだし
imagemagickなんかも引数チェックを通った後の個々パラメータ内で不整合出たらassertでメッセージ流して落ちるし

◆QZaw55cn4c (ﾜｯﾁｮｲ 2247-70g7) · 2020/01/02(木) 22:27:00.54

>>900
assert が発動してアプリが止まるのは終わり方として最悪だとおもいますよ
もし assert が発動する可能性があるんだったら assert ではなくて、きちんとしたエラー処理を記述するべきなのでは？

assert って辞書をみると「断言」「主張」「出しゃばり」くらいの強い意味ですね
私は assert はコメントの一種一様態として使います＝>>893

2020/01/02(木) 22:29:39.05

>>899
えっ？
>>892が正しいという主張？
まあ>>901みたいな考え方もあるだろうけどさ

2020/01/02(木) 22:30:49.81

>>901
assertに引っ掛かったときの挙動は置いとくとしても、assertの処理内容や頻度によっては実行時コストが問題になる可能性も無くはないから、単純にやってよしとはならないと思うぞ。

2020/01/02(木) 23:00:40.06

効率厨はログ出力を見れるGNUemacsのeshell辺りででもwindowsプログラム立ち上げてみ？
プロプラ、オープンソースに関係なく大半のリリースビルドが膨大な出力を出しっパになってる現状に絶望するだろうから

2020/01/02(木) 23:03:44.94

>>905
その環境で動かすと、プリプロセッサ段階で消去されているはずのデバッグ文実行結果が見れる様になるんですか？

2020/01/03(金) 01:04:07.68

>>905
処理内容や頻度によって実行時コストが問題になる可能性があると言っただけで効率厨扱いとはw
既存プログラムでログを大量に出しているからと反論しているが、だからそれがどうしたというのだ？ログを出しても性能的に問題ない範囲、頻度、量で出しているだけだろう。

◆QZaw55cn4c (ﾜｯﾁｮｲ 2247-70g7) · 2020/01/03(金) 03:24:18.79

>>907
assertion は「コメントの一種」という私の立場では、重い assertion の罪は軽い、許容できると感じています

2020/01/03(金) 08:42:01.33

組み込みだとタイミング込みで評価するから
ビルドを切り替えられないんだよね

assertはログだけ出すようにしてるが
ウォッチドッグを効かすってのもありかな

起こり得ないところで使うってのはその通り

2020/01/03(金) 14:46:00.81

ロケット打ち上げ２秒後でassert出ても意味が無いな
そのまま大爆発だ

衝突する0.5秒前でassert出ても意味が無い
時速90kmでそのまま衝突だ

◆QZaw55cn4c (ﾜｯﾁｮｲ 2247-70g7) · 2020/01/04(土) 21:11:48.66

uint64_t を配列の添え字に使えるかどうかって何か規格はありますか？
手元の環境は unsigned int のようなんですが、gcc/ming32-x64

2020/01/04(土) 22:03:02.52

uint64_tどころかポインタも使えるぞ

2020/01/04(土) 22:09:03.08

>>911 何を見て「unsigned int のよう」と言っているの？

2020/01/04(土) 22:28:50.08

>>911
ISO/IEC 9899:2011 (E)

6.5.2.1 Array subscripting
1 One of the expressions shall have type "pointer to complete object type", the other
expression shall have integer type, and the result has type "type".

7.19 Common definitions <stddef.h>
size_t
which is the unsigned integer type of the result of the sizeof operator;

どこにもunsigned intに限定するとは書いてねえぞ
unsigned integerと書いてあるのが
おまえはunsigned intに見えるのか？

◆QZaw55cn4c (ﾜｯﾁｮｲ 2247-70g7) · 2020/01/04(土) 23:21:44.72

>>912-914
コメントありがとうございます
uint64_t と int をいいかげんにチャンポンに使っていたための祟りに襲われてしまっているところでして…
a[i] = *(a + i)
を考えれば、i が int = int32_t, であろうと uint64_t であろうと、うまくやってくれると予想できますね

2020/01/05(日) 12:03:03.18

そこは
[a]i = *(a+i)
だろ

2020/01/05(日) 12:18:38.35

>>916
それを言うならi[a]だ
ドヤるなら動作確認くらいしてからにしろ
そもそも後置演算子の[]が[a]iなわけねえだろ

2020/01/05(日) 12:50:09.43

STLの配列の添え字は、std::size_tと同じ範囲が使えるように思う。
このstd::size_tには長さの制約は多分ない。
常識的に考えて、32ビットのプログラムで64ビットの配列を使うことはあまり現実的ではない。
なので、std::size_tの長さはNビットプログラムにフィットするようにコンパイル時にスイッチされる。はず。