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

2023/08/02(水) 10:53:42.75

>>328
事実如何を措いて、
主流以外の傍流は消滅するという理屈がそもそもおかしい。

2023/08/02(水) 11:00:33.97

バイナリクラックなら開発言語そのものにはあまり意味はない気がするけどな
バイナリエディタで稼働中の実行コード覗かれれば元の言語が何であろうが同じこと

2023/08/02(水) 11:10:57.90

こういうのはやはりファームやってた人は強いのだろうか？笑

2023/08/02(水) 11:11:56.50

暗号化やら難読化やらを駆使しても
実行中には実行できる形になってるのは
どうしようもないもんな。

だからライセンスで制約を付けるんだが、
不特定多数をユーザーとするビジネスモデルだと
制約を守らせるのも難しいのだと思う。

2023/08/02(水) 11:38:35.24

不具合を何度も指摘されても放置していて
痺れ切らしたユーザーが解析してパッチを公開した
これが最初だったと思う

2023/08/02(水) 11:45:48.58

あれ難読化してあるの？

2023/08/02(水) 11:54:41.63

業務用アプリならサブスクとクラウドって感じだろうけど
個人向けのだとどうなんだろうね
まあそういう海賊版はアップロードした奴を捕まえることで対処しているっぽいけど
アプリの制限取っ払われるのはもうどうしようもないんじゃないかな

2023/08/02(水) 11:55:36.50

難読化はしてない
いやらしいほどに丸見え

2023/08/02(水) 20:21:52.90

>>328
オープンソースを勘違いしてる？

2023/08/02(水) 20:58:10.27

質問型式ではなく、自分はこう考えていると書いて

2023/08/02(水) 23:54:36.96

>>328
次元の違う問題を比較してると思う
スクリプトでコンパイル言語を代替できるようになったとしても
商業ソフトを供給するほうがスクリプトでないと実装できないことにはならないし
サーバーサイドで重要な処理を行うようにすればスクリプトでもそこは解析できないわけだし(今回の５ｃｈのAPI仕様変更みたいに)

2023/08/03(木) 04:03:41.71

>>328
主流かどうかはわからんけどJavaのような仮想マシンで動くやつは流行ったな(Androidスマホで採用されたので思い切り流行った)。Perlとかのインタープリタの言語も内部でコンパイルしてから動くのでなんとなく似ている。
こういう風に仮想マシンで動くようにするとOSやCPUが違っても互換性を保つのが楽になる。

2023/08/03(木) 17:16:30.77

tiktokなんかjavascriptでVMを実装してその上で独自のコードが動いてるせいで解析が極めて困難になってる

2023/08/04(金) 08:54:17.97

>>341
こわっ...

**デフォルトの名無しさん** (ｽﾌｯ Sd8a-KN61) · 2023/08/04(金) 15:45:40.86

/* 文字列を反転させる */
#include <stdio.h>
#include <string.h>

void reverse(char *);

void reverse(char *cp)
{
char *p, *q, wk;
p = cp;
q = &cp[strlen(cp)]-1; // strlen()は'\0'を数えないのに1引かないと正しく動作しない
while (p < q) {
wk = *p;*p = *q;*q = wk;
p++;
q--;
}
}

int main(void)
{
char ss[] = "Program123456789";

reverse(ss);
printf("%s\n", ss);
return 0;
}
上記プログラムでstrlenは'\0'文字をカウントしないのに、1引かないと正しく動作しないのはなぜですか？

**デフォルトの名無しさん** (ｽﾌｯ Sd8a-KN61) · 2023/08/04(金) 15:49:34.67

343の訂正です
q = &cp[strlen(cp)-1]です

2023/08/04(金) 15:57:00.72

末尾の \0 を入れ替えたらあかんやろ
"AB" は　strlen() == 2 になって　

0 1 2
[A][B][\0]

こういう配置や

2023/08/04(金) 16:03:23.77

strlen は文字数を返す一方で [ ] の中はオフセット量(0スタートの相対距離)だから

1文字目を指すのはオフセット0 の場所なんだわ

**デフォルトの名無しさん** (ｽﾌｯ Sd8a-rFCo) · 2023/08/04(金) 16:09:46.38

>>>345 >>>346 即答ありがとうございます
自分はまったくそこまで考えてstlrenを使ってませんでした。ありがとうございます。勉強になります

2023/08/04(金) 16:25:43.11

そこまで考えてというかポインタ/配列添え字が 0 から始まるだけの話でな
　1文字目 = (オフセット)0
　2文字目 = (オフセット)1
:
　n文字目 = (オフセット)n-1

他所言語（特に古めのBASIC) だと配列の添え字は 1から始まるのが自然だから
その感覚のままだと　およよ？　ってなる

2023/08/04(金) 16:33:03.37

COBOL, PL/I, RPG, FORTRAN, BASIC, R, Lua, Julia は、1で始まる

2023/08/04(金) 16:45:56.55

BASIC はバリエーションが多いよ。
0 と 1 を切り替える機能があるやつを知ってる。

2023/08/04(金) 22:18:35.44

>>341
そのやり方だとapple審査通らないのでは？

2023/08/04(金) 22:23:16.57

環境はwebkitでvm自体dlしてくるから問題ないということなのか…

2023/08/05(土) 14:06:37.50

>>349
Pascal もよろしく

2023/08/05(土) 21:43:38.19

>>353
Fortranは添字の開始値を指定しない場合は1から始まり、添字の開始値を指定する場合は任意の整数
（負も可）を指定できるが、Pascalは添字の開始値指定が必須で任意の整数（負も可）を指定できるから、
1から始まるとは言えない。

2023/08/05(土) 22:05:05.59

>>350
ああOPTION BASEかあ
N88BASICの頃からあるが使ってるの見たことない

2023/08/05(土) 23:14:06.26

>>354
そういやそうだった。忘れてた。

2023/08/06(日) 12:09:56.49

今時はExcelのセルをCellsでアクセスしたり配列に代入した場合だけ1オリジン固定でちょっと困る
歴史的経緯というよりExcelのCOMオブジェクトの仕様なんだろうけど

2023/08/06(日) 13:13:28.45

配列って
array + sizeof(*array) * index
だから、0からの方が理にかなってると思う
1からの場合は、実行時にアドレスを割り出すときに絶対1引いてるよね…
そこまでしても人間の直感に合わせたかったのだろう

2023/08/06(日) 13:25:15.07

１引いているのはあくまで内部的なもの
それこそ人間の直感に合わせたインターフェイスとコンピュータの都合の良い情報に相互変換するのがプログラムじゃなかろうか
0からのほうが分かりやすいと思うのはプログラマだからだろうし
10個のデータの最後のインデックスは10というのは添え字で考える場合は分かりやすいしね

2023/08/06(日) 14:09:12.01

先頭をゼロと呼ぶか1と呼ぶかならまだマシよ
音楽なんて先頭要素を1と呼ぶだけじゃなく、要素間の差がない事まで、ゼロじゃなく1と呼ぶ

現代人からするとどう考えても頭おかしいが、仕方がない。ゼロの概念がなかった時代から定義が変わらず続いてるらしい

2023/08/06(日) 14:15:40.68

Cはゼロに限らず何もないを示すvoidが無い頃は全部intでやってた時代もあるんだよ
頭おかしいな

2023/08/06(日) 14:37:12.68

voidが何もないことを示すならvoid*の存在のほうが気になる

2023/08/06(日) 14:59:14.25

void だけ特殊な型と考えるしかないのではないかな。大きさが0ビットの型と考えても良いのかも知れないが。

2023/08/06(日) 15:50:27.26

sizeof(void) → 1 だな
これって正式な仕様なのか分からんけど

2023/08/06(日) 16:40:17.07

それgccなんかの独自仕様のはず。void*をバイト単位で計算できるから便利なんだけどね。

2023/08/06(日) 17:35:17.48

それは気持ち悪いな

2023/08/06(日) 17:46:22.79

言語仕様上は void は不完全型とする扱い、かつ sizeof に不完全型を与えることは出来ない。

2023/08/06(日) 17:48:27.27

gccだとsizeof(関数名)も１なんでしょ
明らかにただの手抜き

2023/08/06(日) 17:52:12.98

仕様上の問題は置いておいて
1として扱うと何か良いことあるんでしょうか？

2023/08/06(日) 17:56:04.37

未定義な動作は規格として規格が何ら要求を課さないことを意味するが
但し書きの中に「文書化された環境に特有な方法で処理してもよい」ともある。

GNU C のドキュメントには void と関数 (関数指示子) の大きさについて記述がある。
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
これも規格が認める正しい動作のひとつ。
それはそうとして処理系に固有の挙動に依存するのを避けるに越したことは無いけど。

2023/08/06(日) 18:03:13.82

>>369
>>365にも書いたけど、演算するのにいちいちchar*などにキャストする必要がない。

2023/08/06(日) 18:10:14.29

void* は演算させないという意思表示なこともあるんで
演算できることが良いわけでもないんだけどね。

2023/08/06(日) 18:29:53.89

どんな用途があるかな？デリファレンス先にアクセスできないってだけで十分な気もするが。

2023/08/06(日) 18:36:51.14

任意に渡ってきたポインタ間の距離？