C言語なら俺に聞け 160

2022/12/28(水) 10:40:30.02

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

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

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.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言語なら俺に聞け 159
https://mevius.5ch.net/test/read.cgi/tech/1659623547/

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

2023/04/08(土) 20:36:00.74

なんか、
for(size_t i=0...
と書く人いません？
for(int i=0ではなくsize_tを使う意味はなんでしょうか？

2023/04/08(土) 20:53:31.67

strlen()やsizeofはsize_tなんだわこれが

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd22-6PIS) · 2023/04/08(土) 20:55:09.41

size_tはintよりサイズが大きいかも知れないし、符号なし整数なんだよね。

2023/04/08(土) 21:16:04.49

そのiを主にsize_tとして使う用があるから
もし質問がsize_tとして使う用がないのにiをsize_tにするのか？ということなら、そう書いて

2023/04/08(土) 21:21:03.16

>>838
Cにおいて自然数で表されるべきものには全てsize_tを使うべきだと信じてる人達が一定数いる
大きさ、長さ、個数、順番、回数なんかが該当し、そこにはループカウンタも含まれる
意味の問題ではなく教義や主義の問題なんで、自分の考えと違うコードを見かけてもそういうもんだで済ますのがいい

2023/04/08(土) 21:22:33.45

ほとんどの場合はどっちでもいいかと

2023/04/08(土) 21:37:43.61

size_t と off_t ぐらいは使えよ

2023/04/08(土) 21:42:59.63

終端ヌル文字列の長さが符号ビット分まであったらそれは異常ではなかろうか
オンメモリで処理できるデータじゃないから見直すべき

2023/04/08(土) 22:47:03.50

>>845
んなこたーない
巨大なファイルを扱う時にはそういうこともあり得る

2023/04/09(日) 01:33:51.48

2.2GBのテキストファイル

2023/04/09(日) 09:21:07.72

>>846
そんなもんstrlenで処理するなw
いちいち数えてるのアホらしい
長さを別に持つべき

2023/04/09(日) 10:02:17.83

>>848
100Bだろうが4GBだろうが、テキストファイルをロードする時にはゼロ終端文字列にするだろ
それをstrlenするかどうかは俺の知ったことではない
4GBのゼロ終端文字列が異常ではないというだけだ

2023/04/09(日) 10:03:11.35

ファイルから読むこんで文字列処理する場合とかINT_MAXサイズ以上になる可能性もあるけどINT_MAXの範囲までしか処理しちゃいけないの?

2023/04/09(日) 10:23:33.31

シークしなよ

2023/04/09(日) 10:29:43.09

一方向のみに進むだけならシークでいいけど、対応する値を探したりするには場所情報もいるから

2023/04/09(日) 10:55:25.78

>>849
なんで？
サイズわかってるのに終端つける意味がないわ

>>852
場所を自分で保持してればいいだけだろ

2023/04/09(日) 11:20:12.19

その場所情報を残すためにintじゃ足りないから大きな型を使ったりするけど
シークじゃ戻って対象の文字列の間の処理を再起やってまた進んでってのが面倒くさい

2023/04/09(日) 11:36:10.69

面倒くさがる人はプログラムに向いていません

2023/04/09(日) 11:49:17.45

やりやすい方法があるのに複雑にして分かりにくくするのがプログラマーならプログラマーじゃなくていいや

2023/04/09(日) 12:08:18.91

あるならそれを使えば良いだろ
相談するまでもない

2023/04/09(日) 12:24:20.87

>>853
LoadTextFile()っていう関数を作ったら戻り値は何だ？
const char*だろ
ゼロ終端文字列が返ると思うだろ
もちろん追加でサイズも引数経由で返しても良い
悔しいからって屁理屈をこねるな

2023/04/09(日) 12:31:45.31

>>853
mainは第1引数がサイズで、第2引数の指す先はNULL終端されてるね

2023/04/09(日) 13:05:09.35

>>858
例えば
終端に移動するとき
サイズと比較して超えていたらエラーか終端に切り詰める
データを追加する場合
終端まで移動
こういった普通の作業するのにいちいちstrlenを呼び出すとかありえないからサイズはどこかに保持する必要がある
よって終端記号はムダだよ

2023/04/09(日) 13:39:50.90

>>858
すげー、なんでそんなの決められるの？
サイズ最適なロードしたデバイス名とか途中で割り込まれた回数とかカウントしないんだ、、、

2023/04/09(日) 14:32:05.77

>>860
strlenを使うかどうかは関知しないと言ってるだろ
それでもゼロ終端文字列を返すんだよ
それがC言語のプロトコルだ
1byteケチって何がしたいんだよw
だから屁理屈をこねるなと言ってる

2023/04/09(日) 14:42:47.16

>>862
そんなプロトコルはないよ
例えばread() は読み込んだバイト数を返す
妄想プログラムは程々にな

2023/04/09(日) 14:44:30.71

>>859
mainの第一引数はargvの個数であってサイズじゃないよ

**デフォルトの名無しさん** · 2023/04/09(日) 15:09:35.01

＞こういった普通の作業するのにいちいちstrlenを呼び出すとかありえないからサイズはどこかに保持する必要がある
“こういった普通の作業”をしない場合はstrlenで良いってことだろ？

なんでもかんでもstrlenを使うって話じゃないし
なんでもかんでもサイズはどこかに保持する必要があるわけじゃなくて
用途に合わせて使い分けるのがプログラマーじゃないの？

2023/04/09(日) 15:13:43.40

小生はゴミを分別できるプログラマーになりたい

**デフォルトの名無しさん** · 2023/04/09(日) 15:20:34.92

いちいちstrlenを呼び出す、と言っているけど
ゼロ終端文字列を返す関数はあるしゼロ終端文字列からサイズを得るためstrlenは呼び出すよね？
その後は処理を高速にするためにそのサイズを維持しつつというのはあると思うよ
けどその後呼び出す文字列処理関数があるとして、その関数が削除した文字数や追加した文字数を返してくれるとは限らないわけで
その場合、その都度strlenを呼び出さなきゃいけない場合もあり得るよね？

それぞれが想定する状況がかみ合っていないだけとも思うんだけどね
結局自分が想定する状況なら自分の意見が良い言っているだけで、じゃあ相手の言う状況でも自分の言っているのが正しいかということ自体を否定しているわけではないでしょ？

**デフォルトの名無しさん** · 2023/04/09(日) 15:21:53.57

最後変だわ

×結局自分が想定する状況なら自分の意見が良い言っているだけで、じゃあ相手の言う状況でも自分の言っているのが正しいかということ自体を否定しているわけではないでしょ？

〇結局自分が想定する状況なら自分の意見が良い言っているだけで、じゃあ相手の言う状況でも自分の言っているのが正しいと言いたいわけではないでしょ？

2023/04/09(日) 16:50:03.25

小生だって燃えないゴミを燃えるゴミと言いたいわけじゃないさ

2023/04/09(日) 18:08:42.61

環境商法は嘘でも乗っからないと文句言われるからつれーよな

2023/04/09(日) 18:17:37.00

同じプラスティックを、燃えるゴミ、燃えないゴミ、分別込み、どれで出してもOKらしい
あれはやってますアピールなんだとか

2023/04/09(日) 18:24:47.66

分別よりも、粗大ゴミ、家電ゴミなどの有料ゴミは厳格に扱われる
迂闊に持ち帰ると大目玉食らうらしい

**デフォルトの名無しさん** · 2023/04/09(日) 18:45:27.28

問題があるからそうしているわけじゃなくて限りある資源をリサイクルだからそうしている
「どれで出してもOKらしい」と言うのは論点が間違ってる

あと指定された場所にあるゴミは所有権の放棄じゃなくて自治体への譲渡みたいなモノだから持ち帰りは窃盗になる

2023/04/09(日) 18:45:49.74

条例と法令の違い

2023/04/09(日) 18:49:28.88

いや実際そうだぞ
汚れているプラスティックを分別ゴミに混ぜられると迷惑なんだそうだ
洗剤でゴシゴシ洗って綺麗にしてから出せだとさ

2023/04/09(日) 18:51:41.97

実際PETボトルは回収しても資源として再利用するのに手間が掛かる
だから、飲料メーカーもPETからアルミ容器に切り替えている
アルミはリサイクルが簡単なんだそうだ

2023/04/09(日) 19:02:34.53

迂闊に持ち帰ると大目玉、はゴミ収集業者の話な

2023/04/09(日) 19:07:33.05

基本リサイクルはコスト的にデメリットしかない
一部ではやってますよアピールをしつつ、大半は分別したのをわざわざまとめて燃やしたり他所に押し付けるのが現実
環境商法は理想アピールとかけ離れた現実が弱みになって反社が入り込みやすいジャンルになってるから関わると危険だよ

2023/04/09(日) 19:12:09.18

>>863
お前の大好きなstrlenがそれだろw
支離滅裂過ぎてもはや自分が何言ってるか分かってなさそうw
お大事に…

2023/04/09(日) 19:15:10.49

文字列とストリームの区別が付いてないアホに付き合わないといけないとはな…
そういう奴のコードはバグだらけだろうなw

2023/04/09(日) 19:22:58.30

ま、Cの文字列はバグり易いのは間違いないがな
特にmmapを使うと悲劇が起こりやすい
なのでテキストファイルの読み込みには、LoadTextFileの様な明確な名前を付けて専用に用意するのが常套手段
もちろんゼロ終端文字列を返す

2023/04/09(日) 19:27:24.15

strlenとか使う馬鹿がいるのか
ラベル低すぎ

2023/04/09(日) 20:52:59.04

Linux Kernelでも使われてるけど、ラベル低すぎとは知らなかったw

2023/04/09(日) 23:27:25.54

strlen strcpy strcatのストラ三兄弟は使うな
普通はマクロ定義でスピードアップ

2023/04/10(月) 00:09:17.40

どんなマクロなんだい

2023/04/10(月) 05:24:42.66

>>864
データサイズの話じゃなかったのかよ？
なんで配列のサイズかどうかになるんだ

2023/04/11(火) 00:17:24.82

>>883
なんかこの人おかしくないか？ラベル…？
>>884も変だけど…ストラ３兄弟って…ギャグか？ｗ
最終的に関数名をちゃんとすればどうにかなるみたいだし
そんな話誰が信じるんだよｗ

>>886
859に言ってくれ
明らかな誤りが含まれていたので訂正した

2023/04/11(火) 02:28:47.80

>>887
>>882に言えよ

2023/04/11(火) 06:49:02.21

>>887
訂正ってどこ？　具体的なレス番ｐｌｚ

2023/04/11(火) 07:47:26.88

Cを捨ててCStringを使うC++へ行けってことだろ。

2023/04/11(火) 08:08:42.83

std::stringではなくCStringな変人きたな

2023/04/11(火) 08:55:39.31

>>889
訂正は>>864だが>>859を読んですぐおかしいと思わなかったなら理解できないと思う

2023/04/11(火) 09:23:43.71

>>859 の言ってるのは argv[argc] == NULL となる規定のことでしょ。
それ自体は正しいので訂正することも無い。

2023/04/11(火) 09:41:53.28

MFCに帰ろう

2023/04/11(火) 09:52:04.87

>>893
文字列サイズの話をしているのに文字列配列の要素数の話で「サイズ」と言うのは不自然
859はargvについて誤解してると思う

2023/04/11(火) 15:56:45.30

>>895
残念ながら俺は文字列サイズとかいう造語の話はしてない
853曰く
> サイズわかってるのに終端つける意味がないわ
に対してあえて冗長な設計にする場合があると指摘したまで

>>864もそうだがどうもおまえさんサイズという語の意味を都合良く変動させているようだな

2023/04/11(火) 19:04:39.28

小生は文字列の長さを表すとき、strlenに習ってlengthという語を用いますん

2023/04/11(火) 19:20:48.37

文字列サイズなんて聞くと、配列要素数かと受け取ってしまう

2023/04/11(火) 19:50:55.63

>>896
くだらない言い訳だ
文字列をロードしたサイズの話をしているのにコマンドラインの引数の個数の話にするのは不自然だと感じた

どうでもいいが文字列の終端までの長さをなんと呼ぶのかね

**デフォルトの名無しさん** · 2023/04/11(火) 20:01:03.76

文字列長
文字の長さ
文字列の長さ
長さ

2023/04/11(火) 20:41:17.09

あと、文字数というのも入れてあげて

2023/04/12(水) 02:49:44.30

文字の長さ 3m
重さ 5kg

2023/04/12(水) 02:52:08.54

https://www.shinjuku-i-land.jp/assets/img/art/img_art-list_3.jpg

2023/04/12(水) 02:53:14.30

とても長くて太くて大きくて重そう

2023/04/12(水) 06:48:43.44

>>899
それってあなたの感想ですよね

2023/04/12(水) 08:59:58.23

もうそれ秋田

2023/04/12(水) 11:42:14.25

0終端の良い所は可変長でどんなに長い文字列でもメモリが許す限り文字列を続けられる
もちろんデメリットは長さがすぐに判らない
逆に長さを持って struct {size_t len; char hoge[0]} Str; みたいな構成にするのもありだが
例えば Str *s = (Str *)malloc(len + sizeof(Str)); で確保して使う
後者のデメリットは size_t len の最大値までしか文字を格納出来ないこと
struct {short len; char hoge[0]} Str; みたいな実装もたまに観るからあなどれない

2023/04/12(水) 11:51:49.32

>>838
C++だと
vector の size() が size_t を還して
for(int i = 0; i < v.size(); ++i)
って描くと警告出るので
for(int i = 0; i < (int)v.size(); ++i)
にするとさらに警告出て鬱陶しいから
for(size_t i = 0; i < v.size(); ++i)
にするアホな例はよく観るってどっかのサイトに描いてあった

2023/04/12(水) 12:32:16.29

C++ならイテレーター使えよ…

2023/04/12(水) 12:42:43.03

vectorはランダムアクセスがウリだからイテレータ使わないこともよくあるね

2023/04/12(水) 13:01:34.03

>>899
「文字列の終端までの長さ」ですが何か？

2023/04/12(水) 13:23:26.32

(文字列の)文字数

2023/04/12(水) 13:42:24.69

>>909
コードによってはインデックスでアクセスしたいこともあるから...

2023/04/12(水) 13:57:15.96

「アホな例」と書く意味が分からん
ちゃん型を使うべきだろ

2023/04/12(水) 13:57:40.50

ちゃんと型を使うべきだろ

2023/04/12(水) 13:59:47.55

そもそも「アホな例」じゃないとLP64でおかしなことになるよね

2023/04/12(水) 14:05:32.31

struct X;
void func(struct X[]); //error

struct Y { int a; };
void func(struct Y[]); //ok

不完全型の場合、仮引数の[]はポインタにならない？？
ちな、gccではエラー、clでは通る

2023/04/12(水) 14:17:34.62

C++だと通ったね
gcc/clangのCだとX[]は許されないけどX*は許される

関数宣言より前にX型の定義がないとコンパイルが通らなかった

2023/04/12(水) 14:55:48.73

どっちが正しいのかね

**デフォルトの名無しさん** · 2023/04/12(水) 15:04:32.82

>>907
馬鹿な私に少しだけアドバイスを

それってsize_tのビット幅 < システム（OS)のビット幅と言う条件下での話なんでしょうか？
size_tがシステム（OS)のビット幅と同じならメモリで管理できるものは必然的にsize_tでも表現できると思うのですが
メモリ上で管理できているゼロ終端文字列をsize_tで表現できない場合ってあるんですか？
まあ一部の組み込みとかならあるかも知れませんが……
けどそういう環境の場合strlenなどのsize_tで返す場合でも表現できなくなるわけで、結局size_tに依存することになってどっちでも同じじゃないかと思うんですがどうなんでしょうか？

2023/04/12(水) 15:07:46.44

>>919
規格は知らんけど配列とポインタは違うんだからエラーで弾くのは正論だと思うけどね
通す処理系はその後の整合性をユーザーが担保する前提の思想なんでしょ

2023/04/12(水) 15:09:16.06

>>921
仮引数に限っては*と[]は同じはず
不完全型だけ例外というのは気持ち悪い

**デフォルトの名無しさん** · 2023/04/12(水) 15:15:29.08

>>908
もう一つ無知なる私にアドバイスをお願いします

size_t len　までは文字を格納出来ると>>907から読み取りましたが
sizeof(size_t)==sizeof(int) の場合
vector v のサイズがINT_MAX以上だった場合、　i < (int)v.size()　ではプログラマーが予期しない動作になりませんか？

2023/04/12(水) 15:27:40.89

size_t が符号なし整数型
int が符号付き整数型

2023/04/12(水) 15:34:06.47

>>922
はずだかなんだか知らねーけど、そんなことはどうでも良くてサイズの分からないオブジェクトの配列は作れんって言ってんだよ
操作上の違いはともかく配列として宣言したんなら関数内では配列として扱うってことを示唆してるわけだろ
仮にそのfuncだかって名前の関数の中にX[3]とかX+5って書かれたらどうやってアドレス出すんだってことよ
動作に違いがあるってことは規格がそれを許してる箇所なんだろうけど弾いてる処理系はそういう考えなんだろう

2023/04/12(水) 15:53:08.00

>>925
仮引数はその場に配列を作り出したりはしないという基本が合意できない以上
これ以上おまえさんと話すのは無駄だな

2023/04/12(水) 15:53:49.38

> 規格は知らんけど

この時点で気付くべきだった

2023/04/12(水) 15:55:21.15

Cはアセンブラの代用言語。

2023/04/12(水) 16:36:09.61

>>917
規格的には (関数定義の一部ではない) 宣言の段階なら不完全型であることを許しているように読める。
C99 だと 6.7.5.3 の第 12 段落に書かれている。

> If the function declarator is not part of a definition of that function,
> parameters may have incomplete type and may use the [*] notation in their sequences of
> declarator specifiers to specify variable length array types.

> 関数宣言子が関数定義の一部ではない場合，仮引数の型は不完全型でもよく，
> また宣言指定子列に [*] を使って可変長配列型を指定してもよい。

ちなみに GCC だと以下のようなものもエラーだが MSVC だと通る。

struct X;
typedef struct X Y[10];

2023/04/12(水) 16:59:41.80

>>929
㌧X

安心した

2023/04/12(水) 23:57:31.43

>>917
Cではエラーになるのが規格準拠の動作。
ただし宣言の形式を変えるだけで通る理不尽な制約でありC++では許されるように改められている。
https://stackoverflow.com/questions/50503501/an-error-about-c-struct-array-in-formal-parameter

2023/04/13(木) 00:37:34.59

>>931
そこでも言及されてるけど
型調整 (配列がポインタに読み替えられる) が優先されるか配列宣言子としての解釈が優先されるかって曖昧じゃない？
読み替えより先に配列宣言子として解釈すべきと確信できるような記述ってある？
常識的には曖昧なら厳しい側の制約で解釈すべきだわなーとは思うけど陽には書かれてないように思う。

2023/04/13(木) 02:04:44.32

>>907
昔々の PASCAL はそんな感じだったな。先頭1バイトに文字列のバイト数が入っていてその後に文字列がある。
当然それだと255バイトまでしか入らないのでもっと長い文字列を扱いたい時に苦しむことになる。
まあでも 8 bit とか 16 bit CPU のマイコンやパソコンにそういう高い要求は最初の頃はあまりなかったのでなんとかなっていた。

2023/04/13(木) 02:23:46.11

>>932
プログラム内に制約 (constraint) 違反がある状態なので、前後関係がどっちだろうと
少なくとも制約違反について診断メッセージを出力しないと規格準拠とは言えない。
> A conforming implementation shall produce at least one diagnostic message ...
> ... if a preprocessing translation unit or translation unit contains a violation
> of any syntax rule or constraint, ...

「通る」が警告も出ずプログラム実行までできる状態と解釈してたけど、
エラーにはならないものの警告が出ているならそれも規格準拠とは言えそう。

2023/04/13(木) 08:28:10.40

https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_047.html

仮引数の[]は、一旦は配列として受理し、その後でポインタに調整されるってことか

2023/04/13(木) 08:28:50.25

VCで通るのは、VLAがないからってこと？

2023/04/13(木) 23:35:55.91

間違ってる