C言語なら俺に聞け 152

2019/06/17(月) 18:27:10.41

!extend:checked:vvvvv:1000:512
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言語なら俺に聞け 151
https://mevius.5ch.net/test/read.cgi/tech/1554171817/

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

**443** (ﾜｯﾁｮｲ 9a2c-i8Xk) · 2019/07/15(月) 20:35:21.08

>>474
「misra-c 2004」「misra-c 2012」で検索して！

**443** (ﾜｯﾁｮｲ 9a2c-i8Xk) · 2019/07/15(月) 20:37:59.21

他にも、MISRA-C では、2重ループ内から、一気に脱出できないから、フラグを持ちまわる事になる

このルールも嫌われる

**443** (ﾜｯﾁｮｲ 9a2c-i8Xk) · 2019/07/15(月) 20:48:48.44

組み込みとか医療用では、バグると簡単に人が死ぬから、
MISRA-C を勉強していない香具師が、コーディングするとヤバイ！

だから、コーディングできる資格を作るべきだっていう話も聞く

2019/07/15(月) 20:50:33.69

なんでルールブックが有料やねんあほか勝手にやってろ

2019/07/15(月) 21:07:10.69

>>476
語るに落ちたな
ブランドｖｓブランドの対戦成績を
自分の頭で考えないブランド志向なやつに出せるわけがない

2019/07/15(月) 21:19:39.89

>>481
検索したら出てきた
http://www.c-lang.org/detail/misra_c.html

2019/07/15(月) 21:36:18.18

4.12 必要動的なメモリ割り当てを使用してはならない

って酷くね

2019/07/15(月) 21:47:13.82

俺以外は絶対守れよって思うルールも多々ある

2019/07/15(月) 21:57:44.30

>>482
何を言ってるのか自分でもわかってないだろww
ブランドとかバカじゃね

2019/07/15(月) 21:58:24.78

関数の中盤以降からreturnするならともかく、早期returnまでも認めないのはナンセンスだよな。
杓子定規すぎるわ。

2019/07/15(月) 22:00:39.84

>>484
組込みだと実行時間が読めなくなるのとフラグメンテーションで総容量足りててもエラーになることがあるからしょうがない

2019/07/15(月) 22:06:28.61

>>486
おまえがすがっているのはブランド以外の何物でもない
とぼけたら誤魔化せると思っているならおめでたいやつだ

2019/07/15(月) 22:43:50.22

MISRAをブランドとか言うアホがいるんだ…
まあ具体的な内容には突っ込めないグダグダ君だしなぁww

2019/07/15(月) 22:45:14.79

そもそもうちはMISRAは参考にしてるけど全面適用なんてしてないし

2019/07/16(火) 00:24:39.33

>>491
いや、しろよ

2019/07/16(火) 00:48:27.21

プログラムは書く人によって千差万別
書く物によっては複雑な物を書かなきゃならない
そしてその上でのバグ千差万別
ルールブックなんてプログラム書かない管理者がこれを守れば大丈夫(キリッ
ってするものだろう

2019/07/16(火) 01:07:51.42

普通は大勢で開発するときに必要な取り決めだけどな
そういう規模で仕事しないなら,何しても良いけど

2019/07/16(火) 01:37:13.82

>>494
MISRAは明らかに小規模なプログラムのための規約だと思うよ

2019/07/16(火) 02:37:59.80

大規模なプロジェクトのコーディング規約を決める人がここにいるとは思わないからね
小規模だと思うなら,そのルールでやれば良いんじゃない？

2019/07/16(火) 03:09:26.20

大規模とか小規模とかじゃなく実際にプログラムを書いてると必要になったりとかあるって話で
プログラムを書いた事内物が大規模ではとかいってるのか

2019/07/16(火) 03:18:03.55

そうそう、MISRAはクソ

2019/07/16(火) 03:29:07.35

MISRAを尊重するひとって、returnを書く位置によって返る先が変わると思ってるんだよ

2019/07/16(火) 07:29:02.49

間違ったことばかり書いてあるわけじゃないけどね
現場にそぐわないスキル不足なやつを庇うところには同意しかねるわけよ

> ルール 8.14 必要 restrict型修飾子を使用してはならない

規格票が読めないようなアホの相手はやってらんね
C++が混ざるところでも対策は簡単だし

2019/07/16(火) 07:43:27.01

トヨタのやってることは一つのミスでも人が死ぬということだよ
もしrestrictを使って人が死んだら責任とれるの？

2019/07/16(火) 07:45:28.75

それなら、人が死なないプロジェクトではMISRAは守る必要がないですね。

2019/07/16(火) 07:58:46.16

>>501
規格票を確認しないやつにミスがどうたら言われたかねえぜ

2019/07/16(火) 08:02:25.27

○○を使って人が死んだら責任とれるの？

○○に何でも突っ込めるウルトラクソ論法
ポインタ、共用体、仮定義、数学関数、それから？

2019/07/16(火) 08:50:54.07

>>501
お前が作ってるプログラムはテストしないのか？

2019/07/16(火) 09:07:55.77

>>492
絶対守るべき指標と守った方がいい指標、といった具合に何段階かにわかれていて
別途ルールがあるならば守らなくても良い（無理して守るべきでない）指標もあるよ

2019/07/16(火) 09:35:00.37

上司のバカかバカの上司でも理解できるまでに破壊されたC言語だろ
それを規格と言ってるだけだ

安全かもしれないけど対照実験がないでしょ
安全であることをどうやって確かめたのか論文の欠片も見つからなかった
だからMISRAの安全神話は神話かデマかフェイクニュースだよ

2019/07/16(火) 09:46:10.29

プライドだけは高いこの道30年の社畜が書いた様なルールだよ。
「してはいけない」ばかりでこうしろという記述が圧倒的に少ない。
フレームワークという発想がない。指摘だけ。すべて勘と経験という名の錯覚に基づいてる。

あと内容的に「最適化はしてはいけない」とか書いておけばいいんじゃないかと思う。次は入れて欲しい。

2019/07/16(火) 10:35:01.62

>>463
処理系依存や未定義だけどなんか上手く動いてる
というのは、ちょっと怖い

2019/07/16(火) 12:58:57.36

たまたま動いているのは
処理系のバグかも知れない

2019/07/16(火) 13:18:30.94

組込み系の開発経験者いなくて草
MISRA準拠が納品物の条件にあるんだよ
でもプロジェクト毎にカスママイズするから
100％適用するわけじゃないよ
わけわからんルールは適用除外してる

2019/07/16(火) 14:13:08.82

>>511
> 組込み系の開発経験者いなくて草
ID:y88H95dP0 あたりは経験者だろ

2019/07/16(火) 15:01:33.68

>>511
8進数使うな、とかいやだよね

2019/07/16(火) 15:05:03.91

エディタ上での見栄えで桁合わせに空白を使わず 0 で補ってやらかす

2019/07/16(火) 15:14:31.06

>>513
2進数や16進数は見慣れているんだが
8進数ってどういう時に使いたい？

2019/07/16(火) 15:27:11.60

バイトが6bitの時は便利だったとかいう話だけど、今要らんよね
emacs使っててエンコードがアレだと出てくるね

2019/07/16(火) 15:32:14.71

文字列で [ESC] を埋めるのに \033 を使ってるのを見るぐらい

（2進数のリテラルをマクロでなんとかするとき　一時的に8進化するけど　中の話）

2019/07/16(火) 15:40:10.80

大昔のアーキテクチャは18bit,24bit とかで3bit 区切りが扱いやすかった
今は16,32,64と16進数が扱いやすいって話だね
ゼロ始まりは8進数というのはB言語からきたらしいよ

2019/07/16(火) 15:44:50.30

>>513
いや、もうコンパイルオプションで禁止してもいいレベル

>>515-516
Unix/Linuxのファイルパーミッションが３ビット単位だからと言うのはあるけど今時直書きなんてしないし

>>517
それも "¥x1b" の方が馴染みがあると思う

2019/07/16(火) 16:30:56.95

\0 … 8進数
\x0 … 16進数

2019/07/16(火) 16:37:07.34

>>487
if の nest が深くなってしまう？

2019/07/16(火) 16:54:01.54

>>521
教条主義的に守るなら　そうせざるを得ないだろうね

if (エラー) return ; // 即脱出
後続コード
return ; // 最終

即脱出を禁ずるなら
後続コードは即脱出条件とは排他的なので if (or else) 内に収めるしかない

if (!エラー) {
　後続コード
}
return ; // 最終

2019/07/16(火) 16:58:26.41

goto ___exit; /* 震え声 */

2019/07/16(火) 16:59:45.97

多分 goto も塞がれてる気配w

2019/07/16(火) 17:24:48.72

うちはreturnは最後に一つのみってやつは適用除外になってる
理由はネストが深くなって読みづらくなるから

gotoもネストしたループから一気に抜ける場合のみ使ってもよいことになってる
フラグ使ってbreakで抜けるより読みやすいからね

2019/07/16(火) 17:27:15.45

もちろんgotoも禁止さ。
あと、各関数の頭で引数チェックも必須なのでreturn禁止とのコンボでほぼ必ず正常系処理のネストが一段以上深くなる。
引数チェック必須はISO26262だったかもしれん。

2019/07/16(火) 17:27:59.62

途中のreturn禁止を徹底するなら、ifとかelseの後に2行以上書くの禁止にした方がいいね。
代入だけ許容するくらいでいい。

**デフォルトの名無しさん** (ｽﾌｯ Sdba-Z5NF) · 2019/07/16(火) 17:28:40.15

>>513
0は0x0とか書かなきゃいけないんかね

2019/07/16(火) 18:10:37.85

>515
そりゃもう512色カラー設定に(ry

2019/07/16(火) 18:31:58.85

ここまできたらC言語も禁止だな。
pythonでコーディングしてコンパイルしてやればいい。

2019/07/16(火) 18:35:56.79

結構前から言われてない？
「C言語を使う必要が無いなら使うな」と

2019/07/16(火) 18:47:43.53

pythonを使って人が死んだら責任とれるの？

2019/07/16(火) 18:54:47.98

>>532
大丈夫さ。プログラム全体をtryで囲んで引っ掛かったらprint("手動運転に切り替てください")のコンボがある。

2019/07/16(火) 18:58:26.32

pythonでOSやデバドラ書けるようになったら考えるわ

2019/07/16(火) 20:05:19.62

#define xxx 06
#define yyy 07
//#define zzz 08 // なぜかエラーになる

2019/07/16(火) 20:31:07.37

なぜかはひみつ

2019/07/16(火) 20:54:46.50

>>535
なんてありがちな…

2019/07/16(火) 21:03:30.93

ここらへん嫁
https://programming-study.com/technology/lets-learn-how-to-express-constants/#i

2019/07/16(火) 21:05:08.13

祈りが足りないからだな

2019/07/16(火) 21:08:14.38

ちょっと前に８進数が～ってやってるのに
あ、ネタかw

2019/07/16(火) 21:22:48.20

このスレの人って少し前のレス読まないよね

2019/07/16(火) 21:31:28.73

const char *sの順番が納得いかない
直感的にはchar * const sだろうが！！

2019/07/16(火) 21:32:10.10

char const*だろ？

2019/07/16(火) 22:16:46.03

* const char s
じゃね？

2019/07/16(火) 22:17:34.37

おれは何を言ってるんだ？？

2019/07/16(火) 22:20:37.80

>>542
＞const char *sの順番が納得いかない
＞直感的にはchar * const sだろうが！！

前者はポイントされる文字列が const で、後者はポインタ自体が const でしょ

2019/07/16(火) 22:42:49.53

const char* const s
これも直感的じゃないって言うんだろうか

2019/07/16(火) 22:43:19.23

546です
すみません、それを踏まえてということか…

2019/07/16(火) 22:50:32.56

const は後置で書いたほうが整合性が取れる
char const * const s:
しかし、見た目的にかわいいのは前置である
const char * s;
私はかわいいのが好きである
よって前置は使わない

2019/07/16(火) 22:58:11.13

そこで私が提案したいのが「strong」である
strongは修飾したデータをすべてconstにする
つまり
char const * const s;
と
strong char * s;
は等価である

2019/07/16(火) 23:13:59.86

>>550
安易な予約語の追加は嫌われるよ

2019/07/16(火) 23:18:11.31

「strongがやられたようだな…」
「フフフ…奴は四天王の中でも最弱…」

2019/07/16(火) 23:19:03.80

2019/07/16(火) 23:22:51.61

stringと間違えそうで嫌だなｗ
readonlyはc#で使ってるしな
やっぱconstだな

2019/07/16(火) 23:40:17.89

大文字で CONST にするとか。

2019/07/17(水) 04:24:07.40

フン
char *const_s

2019/07/17(水) 06:33:32.66

>>546
const int a → constなint型のa
const char *s → constなchar *型のs
constなのはchar *つまりポインタ(直感)
char * const s → char *型のconstなs
constなのはsつまり文字列自体(直感)
なんで逆！！

2019/07/17(水) 06:46:44.61

> const char *s → constなchar *型のs

ギャグだよな？

2019/07/17(水) 06:57:50.40

宣言は右から左に読む
const等の修飾は左にかかる
char const * const s; // sは、const *である、const char型の

右にかかるなら↓のように書けないとおかしいがこれは構文エラーである
const char const *s;

変数名はただの識別子で、ある領域にsという名前を付けただけにすぎない
constやvolatileは型修飾子であり、これらが付くのは型に対してである
～という領域を、以後sと呼ぶ、である

2019/07/17(水) 07:14:03.66

ちげーよ
宣言は真ん中から左右に読むんだよ
char const *(* const s)[1];

**443** (ﾜｯﾁｮｲ 9a2c-i8Xk) · 2019/07/17(水) 09:21:48.88

>>526
引数チェックに関しては、Java のコーディングルールでは、
外部の人用のAPI、つまりpublic な関数には、必要

一方、そのモジュール・クラスの実装者が使う、
内部的なAPI、つまりprivate な関数には、いらない

既にどこかで、エラーチェックしてるから、何回も同じエラーチェックするのは、無駄

2019/07/17(水) 21:08:01.97

const char *sは*sがconst
つまりポインタsの指すアドレスにある値が不変だけどsがどこを指すのかは可変

char *const sはsがconst
つまりポインタsがどこを指すかは不変だけどsの指すアドレスにある値は可変

大体こんな認識で合ってる？

2019/07/17(水) 23:04:57.90

あってるけど納得いかないって話
1つ目がまず何で*sにかかるんだよ
自然に読んだらconstはchar *にかかるだろ
右から読むとか頭おかしいわ、アラビア語かよ

◆QZaw55cn4c (ﾜｯﾁｮｲ ba47-iNHA) · 2019/07/17(水) 23:22:42.51

>>563

char * s;

に 1 個の const を追加するとき、形式的に追加できる場所は 4 箇所

a) char * s const;
b) char * const s;
c) char const * s;
d) const char * s;

このうち a) はコンパイルできない
b) c) は可能だが、の二つの間で意味は異なる
d) は本来ならエラーであるべきだと私は考えているが、実際には c) と一緒の意味になっている

2019/07/17(水) 23:34:56.30

C言語使う時はいつ？
早いコードが欲しい時
メモリー消費に無駄のないコードが欲しい時
他ある？

◆QZaw55cn4c (ﾜｯﾁｮｲ ba47-iNHA) · 2019/07/17(水) 23:39:48.74

>>565
他の言語はほとんどわからず（かじってはみたものの使えるまでにはMPがあがらず）、C/C++ でしかまともに書けないし発想できないからです…

2019/07/17(水) 23:42:49.57

>>563
実はアラビア語って可能性はないのか？

2019/07/17(水) 23:49:47.36

そもそもconst char *sの宣言の時の切れ目がconst / char / *s なのも何だかなぁ
const / char * / s でconstはchar *にかかれよｊｋ
現実に間違ってるのは渋々受け入れてるけど開発者が許せない

2019/07/18(木) 00:00:28.28

>>564
自分は b or(and) d かなー

2019/07/18(木) 00:33:34.97

>>565
他に思い付くところとしては、
組み込み環境などで、C言語以外の選択肢がない、または他の言語で実行できる環境を整えるよりCを使った方が楽な場合。
外部のライブラリのインタフェースがC言語で、呼び出す部分をCで作る方が楽な場合。
バイナリファイルの操作などポインタ操作を使って実装しやすい場合。

2019/07/18(木) 00:48:28.58

>>568
単純なポインタのことしか考えないから、左から右にこだわってんだろ。
>>560も指摘している通り、変数宣言の構文は内から外だぞ。配列や関数ポインタも交えて、それらを多段階の組み合わせにしても一意に解釈できるのを理解すれば、合理的な物だとわかると思うよ。

>>563
1つ目は、constがかかってるのはcharだぞ。内側から解釈するとsは*が付いているからポインタであり、それが指す型がconstなcharだ。

2019/07/18(木) 05:33:10.45

char *s
の意味は*sはchar型だよって意味で
sはchar *型だよって意味じゃないよ

2019/07/18(木) 05:43:05.99

>>572
こう理解できてるとわかりやすいね。つまり
const char *s
は
*s(sの指す先)はchar型でさらにconstだよ
となる。

2019/07/18(木) 06:48:06.17

>>572
その宣言から以後、
sという式がchar*型
*sという式がchar型
２つの意味を同時に表現してるんだよ

2019/07/18(木) 07:54:18.60

*と*const があると憶えるべき。

2019/07/18(木) 09:56:03.22

>>563
ポインタを表す * が型にくっついてるんじゃなくて変数にくっついてるからでは？
分かりにくいなら typedef でポインタの型を作ってそれを使えばいいんじゃないな。

右から読む事に関しては英語を日本語に翻訳する時に順序を入れ換えた方が自然な感じになる事があるのでなんとも言えんな。漢文のレ点みたいなものもあるしな。
日本語とは逆順の方が自然な表現になる言語はある。そして歴史的な事情で混在してしまっているのもある(アメリカでの年月日が月日年の順だとか)。
生まれながらにしてその言語使ってればその人にとってはそれが一番自然な表現だからな。

2019/07/18(木) 10:04:50.81

>>574
結果はいっしょでも解釈の仕方は複数ある感じだね。
自分にとって理解しやすいので
char *s
↓
sの指す先はchar型、つまりsはポインタ
って言う風に捉えてる。