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

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

2023/08/07(月) 01:08:17.44

アレじゃないかな？メリットあるとしたら

【struct に含めたメンバーは、サイズゼロはダメ】っていう仕様があったかと思う。
正確には【structの違うメンバーが同じアドレスになったらダメ】だったか

----
以下は蛇足

ただサイズゼロだめってのは例外があって。
structの末尾メンバーでchar[] だか char[0]ってのが、確かC99あたりでアリになった気がする。

これは…それまでも使われてたテクで
【structの最後に char [1] のメンバーを置いて、実際にはメモリ確保の時structのサイズ+可変長部のサイズでメモリ確保し、最後のメンバーを使ってstructのサイズを超えてアクセスする】という慣用句があって、
それの目的で
C言語公式仕様風では char[1] と書き
確か昔は gccだとchar[]
vcだと char[0]
ていう書き方してた。（gccとvcは逆だったかも知れない）

のが、公式仕様でもサイズゼロokになった…という話だったかと。

2023/08/07(月) 01:23:44.93

あ、メリットの言い方をすると

処理系内でstructのサイズ計算を実装するにあたって、あらゆる型がサイズ1以上である事が分かっていれば、合算処理を合理的に実装する事ができる
…よね？

2023/08/07(月) 08:18:18.04

意味不明
メンバーにvoidを含められたとしても参照すればエラーになるはずなので使いようがない
(void*はもともと正しいサイズを持つ)
unionで似たようなことはできる

2023/08/07(月) 09:11:24.17

>>375
サイズゼロをOKとすると言ってしまうと語弊があると思う。
仕様上の理屈だと「不完全型を指定できる」だし、そうした場合の動作は
いくつかの特例で成立していて「長さ 0 の配列」は現れない。

sizeof などでは「フレキシブル配列メンバは無視される」だし、
メンバにアクセスするときは

> 置き換えられた配列が要素をもたないとき，それはただ一つの要素をもつのと同じ規則で動作する。
> しかし，その要素にアクセスした場合，又はその要素を一つ越えたポインタを生成した場合，
> その動作は未定義とする。

とあって、長さ 1 として扱うけど要素にはアクセスするなという回りくどい言い回しになってる。

2023/08/07(月) 10:17:41.09

>>375
typedef struct { int x; char a[1]; } A; A *p = (A *)malloc(sizeof(A) - 1 + N);
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) + N);
typedef struct { int z; char c[0]; } C; C *r = (C *)malloc(sizeof(C) + N);
かな

2023/08/07(月) 10:19:25.16

>>378 の主張だと
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) - 1 + N);
でなければならないのかな

2023/08/07(月) 11:05:26.04

>>379
配列の大きさとして 1 を指定して可変長のように扱うやり方については
ちょっと不明瞭なんだが仕様に厳密にいうと準拠してない方法だと考えられている。
https://c-faq.com/struct/structhack.html

配列の大きさが 0 より大きくなければならないということについては
例外を見つけられないのでどこであろうと 0 を指定したら未定義と解釈していいと思う。

GNU C では構造体メンバの最後の配列要素に 0 を指定した場合は
C99 でフレキシブル配列メンバにしたときとほぼ同じような扱いになることがドキュメント化されてる。
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
つまり GNU C では 0 を指定していいわけだが……結果が同じならあえてやる必要もないな。

GNU C でも構造体の最後の要素を除いて配列の大きさに 0 を指定するのは (可能だが) 推奨されていない。
アクセスした結果は未定義なのでなんの役に立つのかようわからん。

2023/08/07(月) 11:36:51.88

>>380
-1する必要ないな
１バイト程度なら余計に取っても害はない

2023/08/07(月) 14:20:51.17

>>382
そういういい加減な見積もりは感心しないな
それに、この場合は-sizeof(int) が正解だと思う

2023/08/07(月) 14:26:13.65

>>382-383
どっちも間違い。この場合は -1 をしてはいけない。

2023/08/07(月) 20:36:36.16

>>383
いい加減なのではなく無駄なことに神経を使わないのがプログラマの秘訣だ
それに他人が見て「この-1はなんだろう？」と無駄な思考時間を取られる可能性を考えたら百害あって一利なしだ

>>384
よく見たらデタラメだな
すまん

2023/08/07(月) 21:06:32.92

>>385
1バイトごときのために余計なことをしないってのは理解できる理屈だが、不必要な1バイトを確保するってのもそれはそれで無駄に考えさせられてしまう感じがする。
やろうとしていることと合致しないコードなわけだから。
害はないが役に立ってもいないということを確信するのはどういう役に立っているのかを見つけるより難しい。

2023/08/07(月) 21:30:20.59

>>384
ああ、[1]の場合のコード見てたわ、お恥ずかしい。
どっちにしろ[1]の場合もoffsetofかalignof使ってあれこれだね…sizeofじゃ正解ではない…