C言語なら俺に聞け 161

2023/04/21(金) 14:05:20.18

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

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

2023/06/07(水) 21:46:42.98

ダブルスラッシュがコメントに採用されたのどの版から？

2023/06/07(水) 22:41:36.55

>>210
概念的にはgetした瞬間にリングバッファから取り除かれてるはずなので
実際にはバッファが一回りするまで残っているが
消えてるかどうか曖昧で気持ち悪いのでコピーで返したほうが望ましい
まあ好みかもしれんが

2023/06/08(木) 11:06:02.87

>>214
MSVC じゃなくて MS-C の 3 くらいからあったかも

2023/06/08(木) 12:46:07.00

C99から
それ以前でもコンパイラ拡張で//コメントをサポートしてるのはあるらしいけど
以下のようなエッジケースで解釈が変わる

b=a//**/ 2
;

//コメントを認めないならb=a/2;
//コメントを認めるならb=a;

2023/06/08(木) 12:55:42.05

> 目をつぶって作ったのでバグがあっても知らない

そういうのは「作った」とは言わない

2023/06/08(木) 13:01:02.12

盲者のモノ作りなど認めない。

2023/06/08(木) 13:06:43.94

目開けても何も見てない奴いるからな

2023/06/08(木) 13:39:09.53

野良審査員には餌をやらん主義

2023/06/08(木) 14:35:42.49

>>214
C99 からだが経緯としては先に C++ で採用されていたという事情がある。
C with Classes から C++ になる 1984 年頃に BCPL 風を参考にして
スラッシュふたつで始めるコメント記法が導入され、
更に 1998 年にそのコメント記法も含めて ISO の規格として確立した。

C と C++ でプリプロセッサは共用することも多いだろうし
コメントはプリプロセッサで除去するだろうから
C++ で採用された段階で実際には C でもスラッシュふたつのコメント記法を
使えていた環境は割と有ったのだと思う。

2023/06/08(木) 14:52:55.41

マイクロソフトが独自拡張で当時C++のみのはずの//をCでも許していた
言わずと知れた屈指の大手がやっているので規格が追認することとなった

2023/06/08(木) 16:45:48.60

gccも使えてた気がする

2023/06/10(土) 18:04:06.65

90年後半からしか実務で使ってないけどVCでは普通に書けてたな
UNIX系はベンダー製のCの制限が酷かった思い出

2023/06/10(土) 18:47:34.87

borlandやwatcomでも使えなかったっけか？

2023/06/10(土) 20:49:31.43

便利だからね
オプションで使えなくすることもできたはず

2023/06/16(金) 01:45:49.62

int a[3] = {};
int b[3] = {0};

aの初期化はgcc拡張で規格に沿っているのはbの初期化だと記憶していたんだけど、
規格の6.7.8を見るとメンバの個数より波カッコで囲まれた初期化子が少ない場合は暗黙的に静的に初期化するとあった。
この規格の文章を見る限りはaも規格に合致していると思えるんだけど、aがgcc拡張っていうのは本当ですか？

**228** (ﾜｯﾁｮｲ c1bb-s+nx) · 2023/06/16(金) 02:08:30.52

参照した規格はX 3010：2003 (ISO/IEC 9899：1999) です

2023/06/16(金) 08:46:04.94

>>228
本当。文法が空の {} を許していない。
initializer:
assignment-expression
{ initializer-list }
{ initializer-list , }
initializer-list:
designation(opt) initializer
initializer-list , designation(opt) initializer

C23 から↓で initializer に {} が追加されてようやく通るようになる。
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2900.htm

2023/06/16(金) 16:12:05.48

struct hoge {
char a[];
};
struct fuga {
char a[0];
};

2023/06/16(金) 16:20:37.85

>>230
なるほど構文規則ってところを見るんですね
どうもありがとう

2023/06/16(金) 17:28:57.05

>>228
gcc でも -pedantic オプションを付けたら警告は出るぞ。

> warning: ISO C forbids empty initializer braces

2023/06/17(土) 21:50:15.83

>>233
知りませんでした！
どうもありがとう

2023/06/25(日) 08:36:37.75

int main(void)って書く流派ってどこでそんなの身に着けたの？

2023/06/25(日) 09:20:49.86

>>235
ISO/IEC 9899:2011
5.1.2.2.1 Program startup
1 The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }

2023/06/25(日) 10:53:26.83

>>235
この指摘をしばしば見るが、int main(void) が違反だった時代はいつ頃なの。

2023/06/25(日) 10:56:42.79

C99からint main(void)と書いてもいいらしい

2023/06/25(日) 11:13:38.04

main については C89 のときから変わってないよ。

2023/06/25(日) 11:58:52.46

>>237
K&R Cにはvoidというキーワードが存在しなかった

2023/06/25(日) 12:22:01.62

K&R第2版にint main(void)なんて書き方出てきた記憶がないんだよね

2023/06/25(日) 12:38:23.47

printf(null);

2023/06/25(日) 12:38:51.73

>>241
日本語版だと 41 ページに
「リストが明らかに空であるときには，予約語 void を使うべきである」
と書かれているのを見つけた。

2023/06/25(日) 17:09:36.88

関数定義のときに仮引数がゼロ個なら void を書くのは当然の作法なんだから
main についてはどうでも良いとはいえども main だけ空にするのもなんか変じゃない？

2023/06/25(日) 19:26:05.36

処理系は引数で任意のスタートアップを指定できるからmain書きたくない需要も満たせるよ

2023/06/25(日) 22:39:44.42

>>235
めんどくさいだけだろ

2023/06/26(月) 06:14:35.93

めんどくさい流免許皆伝

2023/06/26(月) 07:16:23.26

初級、めんどくさいので略記
初段、めんどくさいので無注釈
免許皆伝、めんどくさいので無ドキュメント

2023/06/26(月) 08:07:26.96

組み込み系ならmainに引き数なんて不用

2023/06/26(月) 08:52:43.48

元々プログラムはまんどくさいを代行するものだし・・・

2023/06/26(月) 12:05:19.83

組み込みでmainか・・・
ベクタテーブル作るときのラベルがマングリングされてないから短く済むけどそれだけ

2023/06/26(月) 12:06:17.67

あ、ここCだっけ
サーセン

2023/06/26(月) 13:00:03.75

>>249
main に引数が有るか無いかの話じゃなくて、無いときに void を書くという話題だよ。

2023/06/26(月) 13:16:56.95

実際の組み込み系には、二つのmainエントリーがある
引数のある奴と、無い奴な

2023/06/26(月) 13:20:15.17

>>254
組み込みでargcとargvはどんな意味があるってんだ？
コンソールがあるって前提？

2023/06/26(月) 13:24:00.16

意味なんて知るか
ブートローダとか色々都合があるんだよ

2023/06/26(月) 13:31:08.91

環境依存しまくってる部分だとは思うけど
組み込み用のコンパイラでもｴﾝﾄﾘは main のままなのね

2023/06/26(月) 13:43:40.71

組込みの真のエントリーはresetな
でも普通はそこからmainまではハード会社が提供してる
初期化処理が入るからあんまり触らない

2023/06/26(月) 16:47:50.70

リンカにわたすオプションで_startだか_resetだかを指定してるだけ(例えばld -e _start)
自分で初期化を書きたければmakefileに先頭ラベルを記述すればいい

2023/06/26(月) 17:33:04.45

割込みベクタテーブルのリセット割込みのアドレスがエントリポイント
マイコンのリセットでプログラムカウンタのアドレスが設定される

2023/06/26(月) 20:20:34.26

>>260
石によるだろそんなん

2023/06/26(月) 20:39:52.87

K&R Cで「死産だった」とされるentryというキーワードは、多分このへんの話だったんだろうな

2023/06/26(月) 20:56:23.88

そもそもCPU(マイコン)と、そのCPUの命令セットに翻訳するコンパイラに自由度を与えるためにC言語規格で明言することを少なめにしてる

0x100からカウンタが始まるだのブートローダーが必要だの環境依存の初期化はコンパイラが知ってれば十分。

2023/06/26(月) 21:02:50.78

コンパイラは知らないよ
スタートアップライブラリが知ってる

2023/06/26(月) 21:10:49.81

そそ

2023/06/26(月) 21:26:51.56

ああそうかコンパイラ自体は初期化手段知らなくてもいいのね

2023/07/07(金) 14:46:28.07

#include <stdio.h>

void stack_size_estimate()
{
int dummy; // スタック上に確保するダミー変数

// スタック上のポインタとダミー変数の差を計算
unsigned long stack_size = (unsigned long)&dummy - (unsigned long)&stack_size_estimate;

printf("Estimated stack size: %lu bytes\n", stack_size);
}

int main()
{
stack_size_estimate();
return 0;
}

Windowsで実行すると毎回結果がばらばらになる

2023/07/07(金) 14:52:43.24

.textと.bssを比較すりゃさもありなん

2023/07/07(金) 15:00:57.31

プログラムとデータは別れてんだよなぁ

2023/07/07(金) 16:12:54.67

アドレス空間レイアウトのランダム化 (ASLR)だろ
差じゃなくてポインターの中身を表示してみればいいじゃん

2023/07/07(金) 16:20:17.47

>>267
64bit 版の Windows だとしたら unsigned long はポインタを表すのに十分なサイズではない。
上位バイトが丸ごと抜け落ちて意図した計算が出来てないと思う。

へんなところを引き算するよりベースアドレスを基準に観察したほうがわかりやすいよ。
歴史的事情で Windows ではインスタンスハンドルがベースアドレスそのものということになってる。

2023/07/07(金) 16:42:49.80

そういやlongはWindows環境だと32bitだっけか
size_t使ったほうが面倒がなさそう

2023/07/07(金) 16:53:06.75

Windows だとどっちでもいいけど意味の上では uintptr_t のほうが妥当だと思う。

2023/07/07(金) 16:55:15.60

いやもう露骨にbit数書いてくれた方がいいわ
int128とか

2023/07/07(金) 17:07:14.08

#include <stdio.h>
#include <Windows.h>

void stack_size_estimate()
{
int dummy; // スタック上に確保するダミー変数
SIZE_T stack_size;

// ダミー変数のアドレスを取得
LPVOID dummy_addr = &dummy;

// メモリ領域の情報を取得
MEMORY_BASIC_INFORMATION mbi;
VirtualQuery(dummy_addr, &mbi, sizeof(mbi));

// スタックサイズを計算
stack_size = (SIZE_T)dummy_addr - (SIZE_T)mbi.AllocationBase;

printf("Estimated stack size: %lu bytes\n", stack_size);
}

int main()
{
stack_size_estimate();
return 0;
}

2096444 bytes
になります、予想の5分の1くらいでした

2023/07/07(金) 17:38:01.25

>>274
#include <stdint.h> の
int64_tとかじゃあかんの？

2023/07/07(金) 17:44:32.91

ここで欲しいのは「ポインタを格納するのに適した整数型」であって
具体的に何ビットなのかをプログラム上で表現するのは筋違いだと思うんだけど
でもまあどうせ処理系に依存するなら抽象を挟んでもあまり得なことも無いかな
とも思うし、まあそこらへんは感覚的なもんやからね……。

2023/07/07(金) 17:46:08.50

>>277
#include <stdint.h>の
intptr_tやuintptr_tじゃあかんの？

2023/07/07(金) 17:49:07.83

>>278
いいよ。
私は uintptr_t が妥当と述べてる。 (>>273)

2023/07/07(金) 17:55:31.01

Windowsならこうなってるね
LONG_PTR SetWindowLongPtrA(
[in] HWND hWnd,
[in] int nIndex,
[in] LONG_PTR dwNewLong
);

2023/07/08(土) 09:25:06.78

それハンドルを取得する関数なのでポインタとはちょっと違う

2023/07/08(土) 11:55:06.89

>>275
それで本当にスタックサイズ計算できてるの？
MSの文書だとデフォルトでは1MBと書いてあるし
もし不足が予想されるのならリンクオプションでサイズ変更できるし
本来大きいメモリはalloc系で確保すべき

2023/07/08(土) 12:43:32.13

メモリ空間は 64bit あるけどその全てに実メモリが割り当てられているわけでは当然ない。
仮想的なメモリを管理するから API の名前に Virtual とついてて、
AllocationBase は管理している一塊の単位のベースってだけ。
その単位の中の全てがスタック用とは限らないので基準にはならないと思う。

各スレッドのスタックの底は thread information block に格納されているはず。

2023/07/08(土) 19:02:15.63

>>281
？？？？

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdbf-yJMt) · 2023/07/08(土) 19:05:04.15

>>281
違うよ。ポインタと同じサイズの整数値を設定できる関数だよん。
型キャストすればポインタも渡せる。

2023/07/09(日) 12:33:23.59

井の中の蛙だったか
あーくだらん

2023/07/09(日) 18:21:47.85

#include <stdio.h>
void main(void) {
int card[5][5];
int *p;

p = card;
}

gccでコンパイルすると
aa.c:7:11: warning: assignment to ‘int *’ from incompatible pointer type ‘int (*)[5]’ [-Wincompatible-pointer-types]
7 | p = card;
となります。
エラーではないので動くのですが・・・この警告はどうすれば消えますか？
やりたいことは、２次元で宣言してる変数cardを２次元を意識することなくアクセスしたくて*pに代入しています。

2023/07/09(日) 18:24:43.97

>>287
p = *card;

2023/07/09(日) 18:31:02.01

>>287
この場合に card の型は int[5][5] なんだけど
配列は配列の先頭要素を指すポインタに暗黙に型変換されるのが基本ルール
だから式中に card が出てきたら int(*)[5] として扱われる。
この型は int* と互換性のない型ということを警告は言ってる。

型が int(*)[5] であるような式に * を付けたら int[5] ということになるんだけど
上述の暗黙の型変換のルールで int* ということになって p の型と一致するようになる。
故に p = *card; で通る。

2023/07/09(日) 18:37:18.48

サンクス

2023/07/09(日) 18:49:34.69

この場合ってpを長さ25の1次元配列として使っていいという保証あるっけ？
`card[0]`の長さ5の配列と`card[1]`の長さ5の配列に隙間がないことが保証されてればいいんだけど

2023/07/09(日) 19:43:00.43

>>291
二次元配列ってのは理屈の上では一次元配列を要素とする配列と解釈される。
一次元配列で要素間に詰め物が入らないなら二次元でも理屈は同じ。

2023/07/09(日) 20:21:15.21

アフォはこう書く
p = (int*)card;
先輩方に見捨てられるので気をつけて

2023/07/09(日) 20:52:22.88

>>291
心配なら
int card[5*5];
とでも宣言すれば安心だけど
パディングがもしあるなら card[5];の各要素の間にすでに挟まってるはずなので
card[5][5];も同じようにアクセスできるはず

2023/07/09(日) 23:01:01.58

>>291-292
隙間の有無とアクセス保証は関係ないでしょ。少なくとも規格上は。

2023/07/10(月) 00:28:02.91

規格上の規定は要素のレイアウトの規定として私は理解してたので
そのレイアウトと矛盾しなければ一次元の配列として
扱っても仕様に反しないという解釈でいたんだが……。
直接的に書かれている演算方法を経由した場合しか許さん
と捉えたなら保証はないのかもしれない。

2023/07/10(月) 00:33:20.12

保証がないと、困るよ・・

2023/07/10(月) 00:36:21.43

解釈の余地があるときは安全側 (制約が厳しい側) で解釈しておくのが筋ではある。

2023/07/10(月) 00:53:08.94

元々配列なんて一次元が基本だし、mallocで確保して多次元配列として扱うなんてのもよくあるし

2023/07/10(月) 01:20:39.58

>>299
malloc で確保した領域はどんなオブジェクト (少なくとも仕様の範囲内で作れる型に対応するオブジェクト) に対しても適切に境界調整されている。
そこらへんは別の話。

2023/07/10(月) 08:43:48.54

先頭と領域が確保されていればその間にアクセスできない部分があることはないだろう
そんな器用なことをする必然性がないわ

2023/07/10(月) 08:47:35.15

#include <stdio.h>
void main(void) {
int card[5][5];
int **p1;
int *p2

p1 = card;
p2 = card[0];
}

2023/07/10(月) 09:02:15.74

>>302
こっちでやれ
https://mevius.5ch.net/test/read.cgi/tech/1427572389/

2023/07/10(月) 09:24:10.89

>>303
おまえそっちでやれ
○○のはずとかそんなんで書くぐらいなら普通に書け

2023/07/10(月) 09:29:04.81

>>304
何のことだよ？

2023/07/10(月) 09:53:48.86

>>301
オブジェクトのレイアウトについての話じゃなくてポインタ演算に制約がある。

ポインタの演算の結果は配列の要素か配列の最後の要素を
ひとつ過ぎた位置を指さなければならない。
その位置にアクセスする (単項演算子 * を適用する) かどうかに関係なく
ポインタの演算の結果がその条件を満たさない場所を指すときは未定義となる。
(C99 なら 6.5.6 の加減演算子の項目に書いてある。)

今回の場合は *card が返すのは二次元配列の「最初の行」を指すポインタなので
このポインタを元に演算した結果が最初の行の外を指してしまったらダメと解釈できる。

仕様に書かれている演算はその演算に相当するレイアウトで配置される
という意味で解釈することも出来ると私は考えていたが
仕様の文面に厳密に言えば駄目かもわからん。

現代的な処理系ではポインタは由来 (provenance) という概念を持っていて
演算の元になったオブジェクトを外れたら未定義であるということを
利用して最適化することもある。
これは実際にある話で、必然性を言うならそれで速くなる可能性があるという理由がある。

仕様に厳密にしないとわけのわからないことが起こるのが C というものなので
仕様の解釈は大事だよ。

2023/07/10(月) 10:31:52.15

>>302
p1 = card; の所はコンパイルエラーが出て欲しいところだが、Cだと警告だけ出して先に進んじゃうかな。

2023/07/10(月) 10:34:39.51

int card[5][5]; となっているとき
&card 二次元配列全体へのポインタ
card 最初の行へのポインタ
*card 最初の要素へのポインタ

2023/07/10(月) 12:23:15.05

2次元配列なんてExcelのRangeオブジェクトが返す配列ぐらいでしかお世話になったことないわ
特に効率的でもないし構造体でええやろ

2023/07/10(月) 12:47:58.91

何でそこで構造体？

2023/07/10(月) 12:53:57.17

>>308 下２行は正しくない。

2023/07/10(月) 13:25:18.46

§6.3.2.1の段落2で定める例外にあたらない場合という但し書きが足りないね
悪かったよ

2023/07/10(月) 18:04:08.51

５ｃｈ、専用ブラウザがサポート終了し、撤退する様です。
FireFoxだと書き込める様です。
それ以外のブラウザも多分大丈夫なんでしょうが、試してはいません。

2023/07/10(月) 18:05:43.31

ソースｐｌｚ