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

ソースｐｌｚ

2023/07/10(月) 18:24:57.71

処理系が16byte境界に合うように
「card[0][4]とcard[1][0]の間にパディングを入れる」ってのが起こりうるか不安

わざわざコンパイラがそんなことする理由は
1. 16byte境界の合わせたほうがindexの計算が速い
2. card[0][5]へのアクセスを不正とみなして、ここへの書き込みを検知するフラグを入れる

規格上パディングが入らないことが保証されるならこの話は忘れてくれ

2023/07/10(月) 18:29:02.59

Talk専用ブラウザ「Jane Style」 ← 5ｃｈの記述が消えました
20230710
Version 5.00 公開
・Talk に対応しました
* 5ch.net のサポートを終了しました
http://janesoft.net/janestyle/

2023/07/10(月) 18:54:15.08

>int **p1;

無いわωωω

2023/07/11(火) 02:24:43.39

>>314
https://agree.5ch.net/test/read.cgi/operate/9240230711/

正確にはJaneStyleが離反した

> 0001５ちゃんねる ★2023/07/11(火) 00:00:00.00ID:LokiTech
> Janestyleはもう5ch.netと提携していません。
> Janestyle以外の専用ブラウザをご利用ください。
> 旧バージョンの5chブラウザ（API前）は近く再度利用可能となります。
> (以下略)

2023/07/11(火) 11:41:03.76

>>315
おそらく連続 (contiguously) というのは間に余計なものが入ることはないという意味で書いてると思う。

2023/07/11(火) 12:37:10.33

テスト

> どういう理屈か知らんけど
> chmateで『URLから開く』で見たい板のURL貼り付けして
> 「5ch」の部分を「5Ch」に変えて開くと
> 5chのスレchmateで見れて草
https://twitter.com/motokamin_/status/1678473238177783835
https://twitter.com/5chan_nel (5ch newer account)

2023/07/17(月) 05:23:15.01

chmate はもう対応できてないかな。俺は読み書きできるようになったよ。
今これはPCからで Siki っていうの使って書いてるが。

2023/07/17(月) 09:16:25.38

旧 API を復活させて制限が緩くなったから昔の専ブラがそのままかちょっとした設定変更で使えるよ。
今のところ PC 用の専ブラとしては JaneXeno か Siki が決定版だと思われているようだ。

2023/07/17(月) 11:31:18.04

>>321
PCはAPI対応前の昔のlive2ch(live5ch)が使える

2023/07/17(月) 11:33:54.45

ninja は make を完全に置き換え可能になったでござるかニンニン?

2023/07/17(月) 11:48:18.17

>>324
設計思想が異なる。
ninja は make ほど多機能ではなく、メタビルドツール (cmake など) と組み合わせるのを前提としている。

どうせメタビルドツールは使うという前提なら ninja のほうが使い勝手が良いと思うが、
そうでないなら make のほうが楽だと思う。

2023/07/22(土) 17:50:40.48

Siki はおすすめ記事が出ていた。

5chブラウザー、JaneStyle代わりのオススメは「Siki」
https://news.yahoo.co.jp/articles/adfd44b291fbc07686ea4735e1397a3287aa4045

2023/07/27(木) 01:32:04.41

現状専用ブラウザJaneStyle4.23を落としてきて修正パッチを当てて動かしてます。
修正パッチは有志が機械語レベルまで降りて解析し対処してます。
今まで無かった機能まで追加してます。その技術力はスゴイですね。

ただ、専用ブラウザは今後５ちゃんねるの仕様が変わったときに
開発者がメンテできるかどうかで生死が決まりそうですね。

2023/08/02(水) 10:02:23.97

なんか昔「コンパイル言語は消滅してスクリプト言語が主流になる！！」って主張聞いて
オープンソースアプリはともかく商業アプリでスクリプト言語使ってたら
速攻解析されてコピーなりクラックされて（その結果どうなるかはわからんけど）商売にならないんじゃないのかと思ったけど
現状どうなのかな？

JaneStyleの不具合発生→ねらー修正っての見てるとバイナリーコードでもスクリプトコードでも解析難易度は変わらないのかなとも思うけど。