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/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

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

2024/01/26(金) 16:28:15.83

参照渡しと実体渡しかw
あれも、アドレス渡しとコピー渡しって言えばいいのにね

2024/01/26(金) 16:55:28.58

アドレスは、数値が主体でそれが何を示しているかの説明の為の単語。
ポインタは変数の一つで *p や p->a 等の動作も含めての設計思想。

などと意味不明な(ry

2024/01/26(金) 17:26:29.97

アドレスは値
ポインタは型だよ
正確にはintのポインタ型とか言うけど

2024/01/26(金) 17:35:02.08

ポインタはポインタ値を格納する場所

2024/01/26(金) 17:36:54.25

場所と言うのは曖昧な表現だな

2024/01/26(金) 18:03:51.31

アドレスは値で右辺値、ポインタは変数でオブジェクトで左辺値
こんな基本的なこと、頼むよ

2024/01/26(金) 18:27:39.65

>>498 正しくない。ポインタ型の変数 int* p に対して p + 1 もポインタだけど、変数でも左辺値でもない。

2024/01/26(金) 18:29:01.58

ある時はメモリーのサラリーマン、ある時はレジスターの探偵

2024/01/26(金) 19:46:30.13

規格上はどうなってるか知らんが
ポインタでいいじゃん統一しろよ
変数へのポインタを取る時アドレスと言いたくなるんやろな
分からんでもないが使い分ける必要はないと思う

アドレスといいつつ結局ポインタでしかないやろ？
場所だけじゃなくて型のサイズも持ってるでしょ？
アドレスと聞くと番地だけってイメージだけど
ポインタっつうのはそれに加えてサイズも持ってるのがミソ

だから不必要にアドレスと言い直す必要はない
だって実際にポインタしか扱わないんだから

2024/01/26(金) 20:04:10.51

アドレスっていう言葉は規格には出てこないと予想してた。
規格にはポインタだけあればよくて、アドレスは実装の仕方のイメージがある。アドレスは多くの場合整数になるが、文字や文字列でもいいというような。

2024/01/26(金) 20:45:56.85

アドレスってアセンブラ屋さんが言う奴？

2024/01/26(金) 21:05:55.41

バイナリーエディタやメモリエディタでも言うよな。

2024/01/26(金) 21:07:17.18

バイナリエディタのはアドレス違うよなぁ
メモリーエディタはアドレスだからいいけど

2024/01/26(金) 21:11:38.94

>>499
p+1はアドレスだよ

2024/01/26(金) 22:21:03.31

ポインターだろ

2024/01/26(金) 22:21:36.46

int a[4] = {0}, (*b)[4] = &a, *c = &a[0];
printf("%p %p\n", b, b + 1);
printf("%p %p\n", c, c + 1);

0x7ffc2026d710 0x7ffc2026d720
0x7ffc2026d710 0x7ffc2026d714

アドレスと捉えると同じ番地だけど
+1の結果が違う番地になるのは
ポインタが大きさを知っているから
これが単なる整数とは違うところ

2024/01/26(金) 22:22:12.95

アドレスと言えるのは直接ハードウェアにアクセスするものだけだよな

2024/01/26(金) 22:29:00.75

規格書の加減算のとこにはp + 1の結果が何になるか書いてある？

2024/01/26(金) 22:36:52.96

p+1の結果は、pの型によって違うやろ

2024/01/26(金) 22:48:45.51

規格ちょっと読んだけど加減算のところには結果がアドレスになるかポインタになるか書いてなくね？

2024/01/26(金) 22:49:56.05

>>512
アドレスはポインタのエイリアスだろ？

2024/01/27(土) 00:39:52.91

だから、アドレスは値で、ポインタは型なんだ
p + 1はpの型によって結果が決まる
intかintのポインタ型かで結果が変わる

2024/01/27(土) 00:55:04.46

>>514
＞だから、アドレスは値で、ポインタは型なんだ
＞p + 1はpの型によって結果が決まる
＞intかintのポインタ型かで結果が変わる

だよな

2024/01/27(土) 01:15:46.64

>>514
規格読み直したら加算の結果はポインタになるって書いてあったわ

2024/01/27(土) 10:42:42.11

>>516
何章？

2024/01/27(土) 14:54:07.21

(int)(p+1)-(int )(p) == sizeof (*p)
だっけ？

2024/01/27(土) 15:00:52.15

>>518
intは32bitのLP64環境ではどうなるんだい？

2024/01/27(土) 15:08:44.06

コンパイルエラーか警告でて下位32bitのみ取得じゃね？
sizeof (*p)がint_max超える設定でもなけりゃ目的は果たせそうだけど。

2024/01/27(土) 16:02:39.58

ポインタは整数に型変換できるけどその値がどうなるかは処理系定義。
変換結果がその整数型で表現できなかったときは未定義。
gcc や clang だとポインタをより小さい整数型に変換しようとしたらエラーになった。

intptr_t や uintptr_t に限っては正しい void* はこれらの整数に変換可能、かつ
void* に再び変換したら元の値と等しいことが保証される。
オブジェクトを指すポインタは void* に変換可能なので
オブジェクトを指すポインタは intptr_t や uintptr_t に (情報の欠落なく、可逆な形で) 変換できる。
しかしポインタが整数でどのような表現を持つかは規定されていないし、
intptr_t や uintptr_t は提供されないこともありうる。

オブジェクトを指すポインタは文字型を指すポインタに型変換してバイト列としてアクセスできることは保証されているので
オブジェクトの大きさを知るためにポインタ操作をするのであれば ↓ のような形にするのはアリなはず。

#include <assert.h>

int main(void) {
int obj;
int *p=&obj;
assert((char*)(p+1)-(char*)(p) == sizeof(*p));
}

2024/01/27(土) 17:07:11.96

はちみつの説明はちっとも頭に入ってこん
3行にまとめてから貼れ

2024/01/27(土) 17:46:47.32

>>518
つまりこのコードはダメってこったね

2024/01/27(土) 18:21:39.29

>>522
関連する規則は関連する規則の数より減ることはない。
根拠不明でいいなら削るけどそんな説明を見たいのか？

2024/01/27(土) 18:27:31.62

3行しか文章解読できないなら、コード書くのは辛いだろう

2024/01/27(土) 18:41:16.06

>>517
「加算」でページ内検索すればすぐ見つかる

2024/02/22(木) 19:08:43.26

errno ってどうしてスレッドごとに別々につかえるの？

2024/02/22(木) 19:34:35.22

>>527
「どうして」というのはそういう仕様になっている理由？
それともそれを実現している方法のこと？

2024/02/22(木) 19:51:00.46

>>528
方法のほうですね
__thread ？とかってgcc固有？って聞いたけど
gcc以外とか大昔とかどうやってんのかなーって