C言語なら俺に聞け 162

2023/10/30(月) 17:13:00.82

!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言語なら俺に聞け 161
https://mevius.5ch.net/test/read.cgi/tech/1682053520/

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

2024/01/17(水) 16:32:50.55

宿題は他所でやれ

2024/01/17(水) 19:42:28.17

do-while文で回す意味ってあるの？

2024/01/17(水) 19:44:52.19

使った人に聞きなさい

2024/01/17(水) 19:49:06.18

>>394
セミコロンをつけさせるため

2024/01/17(水) 21:11:00.53

>>392
答えわかったけど教えない

2024/01/17(水) 21:21:33.14

>>394
2つ以上の文をマクロ関数の形にするときに、C言語の仕様において最も合法安全とされるイディオムだよ

2024/01/17(水) 21:47:57.64

>>394
たとえば
#define MYFREE(p) free(p); p = 0
と定義すると

if( 条件 ) MYFREE( p );
と書くと

if( 条件 ) free(p); p = 0;
と展開されてしまいp = 0;は条件に関わらず実行されてしまう
またこの後にelse節が続くとエラーになってしまうなど不具合の原因になる

2024/01/17(水) 23:38:16.60

>>396,398,399
全然知らなかった
ｱﾘｶﾞﾄ

2024/01/18(木) 11:04:17.52

>>392
その条件下ならない
でもpが左辺値という前提がなかったら変なコトになるコードが書けるね

2024/01/18(木) 11:04:49.16

>>400
396はゼンゼン関係ないんだけどホントに分かってんのか?w

**400ではないが** (ﾜｯﾁｮｲ 6e46-Y4mw) · 2024/01/18(木) 12:19:02.31

>>402
396 と 399 は異口同音と読んでいたが、主旨違うの?

2024/01/18(木) 12:27:08.35

>>402
ブロックではなく do / while にする理由としては関係がある。

2024/01/18(木) 12:41:36.76

二つの文が分かれてしまわないようにするだけならブロックで包めばよくて

#define MYFREE(p) {free(p); p = 0;}

と定義しておけば

if( 条件 ) MYFREE( p );

というような使い方で意図通り動作する。問題になるのは else が付くときで、

if( 条件 ) MYFREE( p );
else foo();

みたいなことをすると

if( 条件 ) {free(p); p = 0;};
else foo();

というように余計なセミコロンが if と else の対応付けを壊してしまう。
かといって MYFREE にはセミコロンを付けない使い方をせよというのも不格好なので do / while で囲むといい感じって話。

2024/01/18(木) 13:15:24.78

はちみつ餃子はいい加減改名しろよ、はちみつ先生によ
どんだけタメになる話すりゃ気が済むんだ
目からウロボロスだぜまったく

2024/01/18(木) 13:17:33.34

>>392
「せよ」ってなんだよ。何様のつもりだ？

2024/01/18(木) 20:39:02.28

#define MYFREE(p) (free(p), p = 0)

のほうが単純

2024/01/18(木) 22:45:02.99

今どきのCならマクロじゃないといけない場合以外はinline使え。

2024/01/19(金) 08:59:45.95

>>409
C の関数は多相化できない。
void* と他のポインタは相互に変換可能なんだが
void* 自体の表現や境界調整要求は環境依存なので

#include <stddef.h>
#include <stdlib.h>
inline void my_free(void** x) {
free(*x);
*x=NULL;
}

int main(void) {
int *x = malloc(sizeof(int));
my_free((void**)&x);
}

みたいなことをして正しく動作する保証はないはず。
この場合は「マクロじゃないといけない場合」だと思うよ。

2024/01/19(金) 11:12:10.18

mallocが返すのはvoid*だし、freeが受け取るのもvoid*なのに？？
保証が無かったら俺達はこれからどうすればいいんだw

2024/01/19(金) 11:13:32.08

printf("Hello, work!");

2024/01/19(金) 11:18:44.53

>>411
void* の話じゃなくて void** の話をしてる。

2024/01/19(金) 11:42:42.67

printf("Konyanyachiwa, Sekai no Kuni kara!");

2024/01/19(金) 12:11:49.63

void**とvoid*は相互に変換可能じゃないのか？

2024/01/19(金) 12:19:49.22

変換が可能だということと同じ表現を持つことは別という話。
int* から void* への変換は変換に関するルールだが
int** から void** への変換によって int* を void* として読もうとするのは type punning の問題。

2024/01/19(金) 12:20:09.89

そうなると、
int** a = malloc(sizeof(int*) * 3);
は、保証無いことになるな
俺達はどうすればいいんだw

2024/01/19(金) 12:25:31.50

void** a = malloc(sizeof(void*) * 3);
の方が適切だったか
これで、a[0]の読み書きが保証されないのは困るよ

2024/01/19(金) 12:27:15.27

>>417
繰り返すが変換の話と表現の話は異なる。
void* は全てのオブジェクトを指すポインタと相互に変は可能であることは保証され、
「malloc が返すポインタに限っては」いかなる型とも適合するように境界調整されていることが保証される。

2024/01/19(金) 12:34:27.05

【AI】Googleの医療面接特化AI「AMIE」は人間よりも正確な診断が可能＆患者への印象に優れるという研究結果 [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583722/l50
【AI】Google DeepMindが数学オリンピックレベルの幾何学問題を解けるAIを発表、人間の金メダリストに近い性能を発揮 [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583476/l50
【AI】大学入試共通テスト、3つのチャットAIに解かせてみたら？　GPT-4はバケモノだった [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705585402/l50
【ナゾロジー】「株価の変動を粒子の振動として理解」量子力学で株式市場の法則を読む！ [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583580/l50
【AI】NTT、自分の分身AIを低コストで作る技術。自分の合成音声を簡単に作れる技術も [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1705583313/l50

ボイス・トォ・スカルのコアプログラムの一部は上記を統合している

2024/01/19(金) 12:39:29.69

何を言ってるんだお前は案件

ポインタの中身は指す対象によってアラインが変わるが
ポインタ自体のアラインは原則一種類しかない

2024/01/19(金) 12:51:29.04

>>421
ポインタは型ごとに異なる表現・境界調整要求を持つ可能性がある。
適合する型へのポインタ同士の場合など同じ表現・境界調整要求を持つ条件が定められているが
最後に「これ以外の型へのポインタは、同じ表現又は同じ境界調整要求をもつ必要はない」と仕様に明記されてる。

具体的な部分は処理系定義なので全部が同じ表現であることをあてにしていい環境ならそうすることは否定しなけど、
常にあてにできるわけでもない。

2024/01/19(金) 13:18:44.56

そうは言っても、
void* p = 0;
と直接生成出来るわけで、void*は値としての意味もちゃんとある
それがvoid**にすると元に戻せる保証が無いのは仕様の不備だろw

2024/01/19(金) 13:22:00.51

>>422
それは「ポインタが指す対象」についての記述で
ポインタ自体にはどんな適当な値を書き込むことも可能(そのポインタを使ってアクセスすると何が起こるかわからないというだけ)
ただポインタにNULLを書き込むだけの関数になんの危険もない

2024/01/19(金) 13:35:18.59

>>424
> それは「ポインタが指す対象」についての記述で

この (>>410) 場合はポインタが指す対象に書き込もうとしている話だが。

2024/01/19(金) 15:18:43.59

>>425
そのポインタは関数への引数であり
すでにvoid*を表すものだと型は決まってるではないか

それとは別に
インライン関数で書いた場合はその場で展開されるから
void* p = 0;と書いた場合と同様にコンパイラが適切な０を書き込んでくれるんじゃないの
つまり(void**)をつけると逆に危険
my_free(&x);
でよい

2024/01/19(金) 16:04:16.95

ポインタで0リテラルだけは特殊でNULLと同義だったのではなかったっけ

2024/01/19(金) 16:16:34.10

>>426
> (void**)をつけると逆に危険

これは暗黙に型変換されることが保証される文脈ではないので付けなければコンパイルが通らないだけ。
(コンパイラによっては黙って通すことはあるのかもしれない。)

> インライン関数で書いた場合はその場で展開されるから

言語の意味論としてはインライン関数は
・同じ定義なら (翻訳単位を跨いだ場合でも) 複数回定義してもよい (定義が一回の場合と同じ挙動)
・なるべく高速に呼び出して欲しいことを期待するヒントである (実現方法は規定しない)

ということになってる。
インライン関数がインライン関数ではない関数と異なる動作にはならない。

2024/01/19(金) 16:39:47.61

>>427
せやで。
厳密に言えばリテラルだけじゃなくて「整数の 0 であるような定数 (定数式) をポインタに型変換したときは空ポインタ」というルール。

これも変換に関するルールであって表現に関するルールではないよね。
実際に空ポインタの内部表現が整数の 0 というわけではない環境は存在するが、
型が正しければ適切に変換される。

2024/01/19(金) 16:53:05.15

>>429
それ規格書に書いてあんの？知らんかったわ
でも

if (!ptr)

みたいなポインタがゼロであることを期待するような式は処理系依存になるでしょ？

2024/01/19(金) 17:02:59.57

>>430
いや、それがよく出来てて、ポインタをそういう形で条件に使うのは問題ない。
単項演算子 ! について「式!Eは，(0==E)と等価とする」というルールになっていて
等価演算子 (==) はポインタと空ポインタ定数を比較したときの結果を規定してる。
空ポインタ定数のほうをもう一方のオペランドの型に合う空ポインタに型変換するルール。

2024/01/19(金) 17:32:06.95

>>431
規格書読んできたけど
6.3.2.3　値0をもつ整数定数式は空ポインタになる
6.5.3.1　式!Eは，(0==E)と等価
6.5.9　==は空ポインタ定数をポインタの型へ型変換する
ってことか
なるほど、規格を解釈すれば!ptrは空ポインタと比較されることになるから問題ないのか
勉強になったわ

2024/01/19(金) 18:55:00.05

NULLは処理系定義だしこの辺はややこしいよね

2024/01/20(土) 00:57:56.71

void*の値は作成出来るけど、表現や境界調整要求は未定義とか、おかしいだろ
Cは現実に則した言語だと思ってたけど、妙な未定義だな
ちなみに、インタープリター型言語を作ったら、オブジェクトはみんなvoid*になる
void*の配列を作成したりとか普通に行われる
もはや規格とか無意味
実装がどうなってるかだけが重要だ

2024/01/20(土) 10:29:05.14

>>433
全然ややこしくないでしょ

2024/01/20(土) 10:30:19.13

> 実装がどうなってるかだけが重要だ
もちろんその通りだけど規格上未定義なわけだから実装がすべて統一されているとは限らないわけで
その実装における「限らない」が問題なわけでしょ

2024/01/20(土) 12:47:01.09

実際に使用する環境に合わせれば良いだけ

2024/01/20(土) 13:33:03.85

各OS毎にABI(Application Binary Interface)が定義されてて、Cの規格で定義されてないところが明確に定義されてる
2つを合わせて現実のC言語なんだよな
だから、JIS X 3010だけを取り上げてどうこう言っても混乱させるだけ

2024/01/20(土) 14:51:47.73

>>434
実際には void* と int* (などのポインタ) が同じ表現なことは多いので
あまり問題 (type punning) にならないと考えるならそうかも。

ただ、表現が同じである環境ならかまわないのかというとそうでもない。
aliasing rules が絡んでくる。
言語仕様上で適合するとされる以外の読み書きをプログラマはやらない (やったら未定義だから) という仮定の元に最適化されることがある。

>>438
ABI はその名の通りインターフェイスを一貫させるための規定であって、
外部に公開しない (外部リンケージを持たない) 部分ではコンパイラは最適化するし、オブジェクトを除去することもある。

私は >>422 で「あてにしていい環境ならそうすることは否定しない」と述べたが、
あてになる確証を得るのは割とめんどい。
言語仕様を調べて分かる範囲で済むならそうする。
少なくとも >>392 をインライン関数にするために手間をかけるなんてことはしない。

2024/01/20(土) 14:57:01.22

だから、その環境が不明瞭なこういう場所で問題になるわけでしょ？
実際>>392では「処理系はANCI C準拠」としか言っていないわけだし

2024/01/20(土) 14:57:54.96

おっと440は>>437-438アテネ

2024/01/20(土) 15:58:08.13

未定義とは規格遊びには便利な言葉だなw
正解はconfigureスクリプトがやってるように、事前に環境を調査して前提にしていい事を明確にして最適な実装をする事だな
なので、言語仕様のみで判断を下す事は不正解と言える
その為にconfigureスクリプトがある
他の言語ではあまり必要ない
Rustとか最近の言語は言語仕様に不明瞭な点は残さないのがトレンドだろう
じゃなきゃそこが脆弱性を生んでしまう

2024/01/20(土) 16:03:47.86

>>392のマクロは、副作用のある式を渡したりするとおかしな事が起きる
全くもって脆弱なものだ
そのままで良いのか？
マクロのままにしておくとか、そっちの方が脆弱性を生む事になる
ちゃんと関数化すべきだろ
その為にすべき事は何だ？
それを議論することが正解と言っている

2024/01/20(土) 16:33:16.28

副作用のある式とは例えば?

2024/01/20(土) 19:48:07.23

p++じゃない？

2024/01/20(土) 19:54:12.68

関数で書いたら問題を避けられるわけ？

2024/01/20(土) 21:49:35.15

C言語で今更議論することなんてないよ
気に入る要らないはモダン言語とかでやってなさい

2024/01/20(土) 22:17:38.62

使用済みのポインタ変数を変なやり方でクリアするとかクソどうでもいい

2024/01/20(土) 22:21:19.13

>>445
それは考えなくていいでしょ

2024/01/20(土) 22:34:47.06

>>446
え？本気でいってんの？
関数で書けば副作用(例えば++p)は1回で済む
当然副作用がある式を書くのはアホだと思うが、少なくとも書いた通りには動く

2024/01/20(土) 22:44:54.31

例えば、(uint8_t)malloc(...) + sizeof(int)を返す関数もあり得る
これは前の方にデータを隠すテクニックだ
実はC++のコンパイラで普通に使われている
これを解放する時は、free(p -= sizeof(int))とやらない事もない
まぁ普通はp - sizeof(int)だろうから屁理屈だけどねw

2024/01/21(日) 00:53:03.43

>>450
解決したい問題はそれだけでいいのか。
それなら意図はわかる。
ただ現実に C の関数を多相化できないのは変えられない前提としてある。
異なる型で扱う必要があるんだから異なる関数を用意するしかないのはどうしようもなくない？

2024/01/21(日) 11:37:01.81

多相？
仮にポインタ変数のアドレスを引数で渡したい場合であってもvoid ** じゃなくvoid * を使って、
人間同士がドキュメントだろうが喫煙所だろうがで問題解決しろよってのが規画と整合する答えなんじゃないの

どうせキャストするんでしょうに
バカですか

2024/01/21(日) 12:09:29.26

void* に変換したなら元の型にキャストしなおさないと保証された動作はほとんどない。
(逆に元の型に変換したときは変換前の値と一致することは保証される。)
元の型を知っているプログラマがキャストすることを期待できる qsort のような使い方なら問題にならないけど、
void* の形で受け取るだけでは関数が出来ることはほとんどない。

文字列を指すポインタに変換してバイト列として読み書きすることはアリなので
オブジェクトの内容はどうでもいいメモリブロック操作系の関数 (memmove など) だとかでも問題はないかな。

2024/01/21(日) 12:53:39.98

簡単な問題だったんだけど答えられる人ほとんどいないのか
相変わらず本題とは関係ない問答しだすアホらもいるし

2024/01/21(日) 13:01:11.71

答えられる人はいるだろうけど、宿題丸投げするやつにエサを与えたくなくて
敢えて書かない人もいるだろう。

2024/01/21(日) 16:35:59.78

ANCIとか頭悪そうな学校で相手したくなかった

2024/01/21(日) 16:43:50.02

誰も知らない新規格、か・・・

2024/01/21(日) 16:44:16.43

宿題スレは別にあった様な気がする

2024/01/21(日) 20:09:55.64

つ https://mevius.5ch.net/test/read.cgi/tech/1434079972/

2024/01/21(日) 22:42:42.89

UNCI はどうだろう。

2024/01/22(月) 09:16:06.10

>>445

free(p++);
p++=0;　←ここで文法エラーになるから

2024/01/22(月) 19:23:27.59

このマクロでそんな心配せんでええやろ

2024/01/22(月) 20:21:33.49

Cに引数の参照渡しってあったっけ?
ないとしたら>>392のMYFREE(p)をマクロではなく関数として書き
その中でp=0としても呼び出した側の変数は変えられないわけで
関数にすることで動作が変わってしまうことになるはずだけど

2024/01/23(火) 13:25:33.99

そんなこんなでp++マクロには問題が多いからC++が出来たってわけ

2024/01/23(火) 14:30:32.20

なんだそんな理由だったのか・・・

2024/01/23(火) 14:41:04.92

mallocとcallocの引数の指定の仕方が違うのが気になる
これ別であることに理由あるの？

2024/01/23(火) 15:14:53.60

>>467
言語仕様上は calloc が返すポインタ (によって表されるメモリ領域) は
malloc が返すものと同じようにあらゆる型に対して適切に境界調整されることになっているし、
ゼロクリアするという違いも「全てのビットがゼロ」という意味なので型の性質を考慮しない。
つまりふたつの引数として指定することによって得られる恩恵はない。

実装がまともなら calloc(a, b) としたときの a*b が size_t の大きさを超えてしまうようなときでも
ラップアラウンドして小さな領域を確保するのではなくエラーにしてくれることは期待できる
(間違いを検出しやすい) が、それを理由として引数ふたつにしているというわけではなさそう。

最初に言語仕様をまとめたときに主要な処理系がだいたい準拠ということになるようにしたはずなので
その頃の処理系でなんか理由はわからんがそうなってたって程度の話だと思う。あまり意味ない。

2024/01/23(火) 15:47:25.62

メリット無いなら統一してほしかったよ

2024/01/23(火) 16:35:32.21

好きな方を使いましょう

2024/01/24(水) 09:58:59.16

統一したらゼロクリアするかしないかだけの違いにならん？

2024/01/24(水) 16:48:12.72

zmallocというマクロを定義すれば解決

2024/01/25(木) 18:11:36.02

callocはmallocのゼロクリア版として *も* 使えるがそもそもの使い方が違う。

2024/01/25(木) 20:28:54.55

ちなみに C には厳密にいうと価渡し(call by value)しかない
値としてアドレスを渡すので結果として参照渡し(call by reference)
ができることになる

2024/01/25(木) 20:55:09.83

参照って言うと色々誤解を受けるから
Cの場合はアドレス渡しで良いと思う

2024/01/25(木) 21:27:23.28

ヘンな用語作るのやめて
ポインタで渡しても値渡しのまま
foo(int x) {int y = 0;x = y;}
bar(int *p) {int *q = 0;p = q;}
呼び出し元の変数に作用が無いのは同じ
両者は等しく値渡しのまま

baz(int *p) {int y = 0;*p = y;}
これについては値渡しされたものがポインタ型だったため
ポインタ型が持つデリファレンス機能によってポイント先に代入できただけ
*** 値として渡し ***て、デリファレンスして、代入しただけ

qux(ref int x) {int y = 0;x = y} // ウソ文法
みたいなことして呼び出し元に代入できるものが
これのみが参照渡し

参照渡しがある言語ならこんな誤解はしなくてすむ
https://www.gnu-pascal.de/gpc/Subroutine-Parameter-List-Declaration.html#Subroutine-Parameter-List-Declaration
> procedure DoIt (x: SomeType);
> Technical: The actual parameter is passed by value or reference, but if passed by reference, it is then copied to a local copy on the stack.
> What it means: you can modify x inside the routine, but your changes will not affect the actual parameter (and vice versa).

> procedure DoIt (var x: SomeType);
> Technical: The actual parameter is passed by reference.
> What it means: modifications to x inside the routine will change the actual parameter passed in.

ポインタを含むあらゆる型に対して、値渡し/参照渡しが存在する

2024/01/25(木) 21:48:36.73

JIS の用語集やそのもとになった ISO 規格によれば call by address の定義はパラメタの場所を渡すこと。ポインタの形であっても場所を渡しているには違いないからあてはまるし、勝手な創作用語というわけではない。
言語の理屈ではポインタもポインタという型の値だがそれの活用方法に名前が付いて悪いってこともない。
言語仕様の話をしているときに混ざってくると「んっ？」とは思うが。

2024/01/25(木) 23:01:13.98

ポインタなのに値渡しとか言ってる奴まだいるのかw
そういうのはポインタ渡しで良いんだよ
アドレスを値渡し→ポインタ渡しでいいんだよ

2024/01/26(金) 00:30:31.26

>>472
zalloc にしようぜ

2024/01/26(金) 00:35:29.44

>>478
＞アドレスを値渡し→ポインタ渡しでいいんだよ

だよな。

2024/01/26(金) 08:38:30.55

Cの文法規則がいいかげんなんだよ

2024/01/26(金) 09:12:22.82

>>481
＞Cの文法規則がいいかげんなんだよ

だよな

2024/01/26(金) 09:47:41.79

アドレスと言う値を渡してるのだからどちらも同じ事だろ

2024/01/26(金) 10:37:55.79

いい加減なところが好かれる理由

2024/01/26(金) 10:46:46.89

アセンブラまんどくさいから作ったのがC
だから型がイイカゲンなのはアセンブラやってる人が対象だから

2024/01/26(金) 10:52:28.10

イイカゲンにしてるとコンパイラの最適化を有効にしたときに破綻するぞ

2024/01/26(金) 12:43:22.79

>>483
構造体は値渡しとアドレスの値渡しがある
どっちも値渡しというと訳が分からなくなる
なので、構造体は値渡しとポインタ渡しが出来ると言えば便利だ
そうすれば、配列は値渡しが出来ないとも言うことが出来る

2024/01/26(金) 13:17:11.83

C++で参照が登場したので「アドレスの値渡し」とか言っている訳で
C++を知らんと意味不明だし違和感あるだろうな

2024/01/26(金) 14:03:32.73

C++がどうのとかは全然関係ないでしょ

2024/01/26(金) 14:07:19.39

C++ とは関係ないと私も思う。
仮引数と実引数の関係は (型がポインタかどうかに関係なく) 値の代入であるということになっている。
繰り返すが言語仕様上の理屈では解釈の余地なく全ての引数は値呼びのメカニズムで規定されているよ。
C++ の参照と区別するための言い回しではなく仕様上の理屈通りに言えばそうなるってだけ。

2024/01/26(金) 14:12:08.41

それで結局
&var
の値はポインタなの？アドレスなの？
どっちでもいいんだよね？

2024/01/26(金) 14:57:45.80

「アドレス」と「ポインタ」の使い分けはイマイチわからないんだよなー。どっちでもいいと思う。
単項演算子の & にはアドレス演算子という名前がついていてアドレスを返すとも書いてあるのでこれについてはアドレスと言っていいのは間違いない。
ポインタは型の種類のように使われてることもあるし、ポインタ型の値のことを指しているように見える箇所もある。
個人的感想としてはアドレスのほうが低レイヤ寄りの概念でポインタは型で意味付けしているような雰囲気を感じてるんだけどあまりはっきりしない。