C言語なら俺に聞け 159

2022/08/04(木) 23:32:27.83

!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

C2x ドラフト
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.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言語なら俺に聞け 158
https://mevius.5ch.net/test/read.cgi/tech/1640401906/

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

2022/09/11(日) 14:32:58.51

レス㌧x

カレンダー時間で表現できるか否かということは
tm_year, tm_mon, tm_mdayのことで、tm_ydayには該当しない議論だよね
逆にtm_ydayに合わせるように補正はしないとなると
ここに優先順位があるのかな

2022/09/11(日) 14:34:54.92

すまん、ちょっと外出する
夜には戻る

2022/09/11(日) 14:37:22.22

あらほんとだ。戻り値の説明しか見てなかったわ

2022/09/11(日) 15:00:19.15

>>182
そもそもtm_wdayとtm_ydayは更新されるって書いてあるし
関係ないけど
・tm_mday: 1 から 31 の範囲の日付。
・tm_mon: 1 月からの月数 (0 から 11 の範囲)。
なのは毎回もやるわ、なぜ両方0スタートじゃないのか...

2022/09/11(日) 15:04:45.97

>>185
月は (英語では) 月の名前に置き換える (配列から名前を引く) という都合から自然にそうなったという説は聞いたことがあるな。
日は番号をそのまま表示するもんだから最初から番号通りのほうが都合がいいし。

2022/09/15(木) 17:53:22.84

ローカル変数の宣言で、宣言しようとしているポインタの初期化子に、同じ文で
宣言された変数を参照するのは規格上OKですか?

/* test1.c */
1 | int main(int argc, char **argv)
2 | {
3 | char s[100] = {'A'}, *p = s;
4 | int i = 10, *a[10] = {&i};
5 | return 0;
6 | }

最新の gcc で試したところ、-std=c89 -pedantic の場合に下記の警告が出ます。
特に3行目が OK で、4行目が駄目な理由がよく分からないです。
どちらもスタック上の相対位置はコンパイル時に決まると思うのですが。
Cの文法について詳しい方、教えてください。

gcc --version
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-1)

gcc -O0 -std=c89 -pedantic -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -c test1.c
test1.c: In function ‘main’:
test1.c:4:27: warning: initializer element is not computable at load time [-Wpedantic]
4 | int i = 10, *a[10] = {&i};
| 　　　　　　　　　　　^

gcc -O0 -std=c99 -pedantic -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable -c test1.c
警告なし

2022/09/15(木) 20:06:58.44

C99より前は集成体(配列、構造体)に対する初期化子定数式(アドレス定数式)でスタックは認められていないっぽい
3行目の初期化対象は配列じゃないでしょ

2022/09/16(金) 06:50:50.62

int main(void)
{
int a = a;
}
これもＯＫなんだが

2022/09/16(金) 19:26:37.47

>>189
スタック上のアドレスを使ってポインタを初期化できるかって話だろ

2022/09/16(金) 19:31:34.25

>>187
{&i}だけだったら初期化は簡単だけど
その書き方だと本来{&i,&グローバル変数,NULL...}などと書けるのでそうなると特殊な初期化が必要になるんじゃないかな

2022/09/16(金) 19:59:25.14

一見
スタックに実体をもつ配列の先頭はセーフで (3行目)
スタックに実体をもつ変数のポインタはアウトというふうに見えるけど (4行目)
{ } の中か否かの差もあるんやね

2022/09/17(土) 00:57:57.08

>>190
そんなん言い出したら自動変数をポインタで指せるのかさえ怪しくなってくるな

2022/09/17(土) 12:49:57.03

スコープ内でアドレスが参照されたならば
自動変数はレジスタ変数にはならなくなる
「自動」の意味

2022/09/17(土) 19:52:14.52

win10(以下win)
strawberry perl入れた時一緒にいれたgcc

wsl
ubuntu22.04 gcc

どっかでみた配列関係のサンプルで
(間違えるとnull見つかるまで一生探し続けるよ的なコード)
で試したら

winで値がおかしい
linuxで正しい

とりあえずwin側でgdbで見ると
winで格納アドレスが逆順になってました
例えばコード上で

array1うんたら
array2かんたら

とあって
array2がアドレス100番台
array がアドレス200番台
みたいになってました
この挙動は環境依存なのかバグなのか知りたいです

まぁ結局両方windowsなんですが

2022/09/17(土) 19:56:51.12

ネットワークオーダーとかエンディアンとかが絡んでる可能性はあるけど、コードを見ないとなんとも

2022/09/17(土) 20:03:08.34

>>195
抽象的すぎて全然わからんｗ

2022/09/17(土) 20:04:45.56

コードは
https://www.delftstack.com/ja/howto/c/length-of-char-array-in-c/
手入力でミスってたらごめんなさい

2022/09/17(土) 20:08:18.29

因みにこっちのwin環境だと
上サイトで24byteになるはずの所が10byteになります

2022/09/17(土) 20:22:45.77

strlenのことか？
文字列と違ってchar配列の末尾には自動的にnull挿入されたりしないから、nullまで数え上げるstrlenが何を返すかわからないし、環境によってはメモリアクセス違反で落ちるかも

2022/09/17(土) 20:26:08.77

いや多分違います

アドレスが逆

多分ここが重要なんですがその原因が
と言うところです

2022/09/17(土) 20:44:25.86

環境依存です
ゼロで終端されていないものにstrlenを呼んではいけません
そのコードが誤り

2022/09/17(土) 20:51:16.94

うーん
そう言うことじゃなくて・・・
なんでメモリアドレスの格納が逆になるの？
と言うところです
cの規格的な話じゃなくてですね・・・

2022/09/17(土) 20:58:26.77

そのページを作った人の環境(コンパイラとバージョン)ではarr,arr2の順で
あなたの環境ではarr2,arrの順なんでしょ
たまたまそうなっただけです

2022/09/17(土) 21:10:35.35

文系脳で行き着く先っていつもそうなんですよね
でも残念ながら「それ」がないんですよ
この世界

たまたま
なんかわかんないけど
偶然
楽しけりゃいいじゃん

なんで生きてるのお前？

馬鹿は嫌い回線で首でも吊ってろカスが

ジパング馬鹿しかいないからもう寝る

2022/09/17(土) 21:15:00.75

オタクくん怒って寝ちゃったw

2022/09/17(土) 21:44:56.47

スタックはアドレス高位から低位の方向に積まれることが多いから、arr2のアドレスがarrのそれより小さくなるとかですかね

2022/09/17(土) 21:46:48.25

そういう人を落とし込める記述はやめよう

2022/09/17(土) 23:27:39.41

スタックの方向などは環境依存だろ

環境依存は他にも、little/big endian とか、
char が、0～255, -128～127 のどちらなのかとか

文字コードが、BOM 無しUTF-8 以外とか

2022/09/18(日) 01:46:10.06

gdbの使い方、ここで質問してもいいですか？

2022/09/18(日) 02:19:18.49

>>210
大きく言語自体から脱線するようだとあまりよくないかなと思うけど、
ささいなことなら多少は良かろうと思うし、程度次第じゃね。

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/18(日) 02:40:43.36

>>209
UTF-8 に BOM は本質的に不要です
なぜならば BOM = Byte Order Mark ですが、UTF にバイトオーダーなど存在しません
BOM なし、と断ること自体、頭が悪い証拠を如実に表出していると愚考させていただきます

馬鹿は死ね

2022/09/18(日) 02:43:34.57

はじめてのC言語完全入門！【Hello World〜ポインタまで徹底解説】
91,121 回視聴
freeCodeチャンネル

2022/09/18(日) 03:28:52.56

>>212
BOM はエンコード方式の識別に使われる場合もあると公式 (unicode consortium) の資料に書かれている。
BOM が BOM という名前である以上は本来の用途からの転用ではあるが、
バイトオーダーだけを根拠にして不要と断じるのはエンジニアリング的に良い姿勢ではないな。

2022/09/18(日) 04:26:41.31

>>212
いい大人がバカとか4ねとか言ってるの見ると悲しくなってくるわ
人付き合いをろくにしてこなかった精神的にガキのおっさん痛すぎる

2022/09/18(日) 05:15:19.35

>>205
めちゃくちゃだよアンタｗ
文系ポエムは他でやんなさい

2022/09/18(日) 05:26:48.38

>>205
よく見るとそのページ内容がむちゃくちゃだなｗ
データが格納される順番はコンパイラ依存なのでそんなサンプルコードは作ってはいけない

「まず、arr のオブジェクトサイズは 24 バイトと表示されますが、」じゃねえよｗ
「内部の詳細を無視してしまうと恐ろしいエラーが発生する可能性があります。」もう起こっているｗ

以上

2022/09/18(日) 10:38:22.56

>>198
そもそも上のコード
size = 24 bytes
size = 17 bytes
この２つはどこから出てきたんだ？
printCharArray　のあとの　printf("size = %lu bytes \n", ... ); はひとつしかないのに

>>195
array1とarray2がそれぞれスタックに積まれるなら　array2、array1の順は正しいし
array1とarray2がリテラルとしてコード上に存在するならarray1、array2の順は正しい
ただの最適化の問題じゃないのか

2022/09/18(日) 13:53:49.44

文系は全称と単称の区別が出来ない
大抵の馬鹿はこれで判別出来る

2022/09/18(日) 14:04:23.72

そういう表現も、大体根拠が希薄
血液型占いと同程度

2022/09/18(日) 14:12:29.01

>>203
規格では一切順序の保証はないので
同じ結果が欲しければそのぺーじと同じ環境を用意してください

2022/09/18(日) 18:22:49.00

機械翻訳まるだしだし
Pythonのおまけで載ってるだけだから
そんなページあてにするなとしか

2022/09/18(日) 18:23:22.20

>>212
Windowsのメモ帳でUTF-8で保存するとBOMが先頭に入った状態になるよね。
そういう変な出力をするソフトがあるせいでUTF-8なのにBOMの有無を意識しなきゃいけなくなるんだよ。

2022/09/18(日) 19:08:21.37

>>223
UTF-8 ではない形で保存されている可能性はいつでもあるわけだが……。

2022/09/18(日) 19:35:00.75

メモ帳で保存する場合、選択はこの中から

https://i.imgur.com/eJf3vLE.png

2022/09/18(日) 20:14:09.21

wcharはutf8圧に負けて廃れるんかね
Cのようなロートル言語使ってると固定幅(但し幅は決まっていない)エンコの有り難みをひしひしと感じる

2022/09/18(日) 21:11:58.46

ストレージはutf-8
メモリーはwchar_t
じゃね？

2022/09/18(日) 22:03:00.04

>>225
それでBOM付き選んじゃうやつが居るんだろうな。選択肢無くして欲しいものだ。

2022/09/18(日) 22:05:23.89

>>226
入出力でJavaみたいに変換すれば良いじゃん。
iconvライブラリとか使って。

2022/09/18(日) 22:23:37.69

>>229
ふぇふふ…

2022/09/18(日) 22:58:27.34

メモ帳は、BOM 付きUTF-8 になるから、ダメ

BOM無しUTF-8は、VSCode, サクラエディタなどを使う。
TeraPad は、新し目の文字に対応していないので、ダメ

2022/09/18(日) 23:06:51.28

メモ帳、デフォルトでBOM無しで保存する
BOM付けるにはセレクトで一番下を選ぶ操作が必要

2022/09/18(日) 23:10:07.79

UnicodeのBOMはUTF-{8, 16, 32}で並び順が違うから判別に使える
逆に無いと推測に頼るしかない
メモ帳はSJISのテキストを開かれることもあるから、BOM無しUTF-8の場合は推測している
BOMが有れば確実に判別出来る
なのでBOM付きUTF-8は悪くない

2022/09/18(日) 23:10:14.33

WindowsではBOM付きのほうが便利だけどね。

2022/09/18(日) 23:12:31.63

gccもBOMに対応したことですし。

2022/09/18(日) 23:23:26.35

UTF-8にBOMが要らないと主張しているのは今の現実について言っているわけじゃなくて
「UTF-8しか存在しない美しい世界」を目指している活動家だからな。
説明したところで話が?み合わない。

**212** (US 0H7f-G1yF) · 2022/09/19(月) 00:00:08.46

>>236
よくわかっていますね、実はそうなんですよね

2022/09/19(月) 00:15:30.26

自覚したなら今度からはバイトオーダーにかこつけたアホな主張はやめとけよ。

**ハノン** ◆QZaw55cn4c (US 0H7f-G1yF) · 2022/09/19(月) 00:18:28.74

美しい世界（爆笑）のために、今後も活動を続けていきます！

2022/09/19(月) 02:37:34.04

ユニコードの上位セットであるGB18030もあるんだけど。

2022/09/19(月) 11:10:12.09

>>236
そんなあなたに Nim がおすすめ

2022/09/19(月) 11:11:36.70

>>233
ASCII (8bit以内) しかないテキストに BOM 付いてたらさすがにうざいと思う

**ハノン** ◆QZaw55cn4c (US 0H7f-G1yF) · 2022/09/19(月) 11:21:09.68

>>242
ですよね！
コードは普通コメントも英語で書くし、なんで BOM がつかなきゃならないのか意味不明なんですよ、ましてや UTF-8 に BOM つけてもいい規約なんて後付けなんでしょう？
美しい世界（爆笑）のために今日もがんばります！

2022/09/19(月) 11:40:57.93

>>241
まさに今、話が噛み合わないことを痛感した。

2022/09/19(月) 11:41:54.30

なくても使えるなら、ない方が良い

2022/09/19(月) 11:43:27.96

どれでもいいけど規格で決めないという対処には愚痴を言いたくもなる。

2022/09/19(月) 11:55:32.42

>>242
ウザいの定義を言え
普通にテキストエディタで編集してるだけなら気付きもしないだろう

2022/09/19(月) 12:00:13.75

気付かなかったあなたはたぶん幸せ者です

2022/09/19(月) 12:13:35.24

10年前ならともかく今時BOMの有無で困ることなんてほぼなくね？

2022/09/19(月) 12:30:39.37

BOMなしUTF-8のデータを読ませるとエラーになるプログラムを作ったやつがいる。
こういうやつをどうするべきか？

2022/09/19(月) 12:33:02.11

市中引き回しのうえ、磔獄門で

2022/09/19(月) 13:00:37.09

仕様で読めることになっているのにエラーになるならバグだがそうでないなら読ませる方が悪い。
日本語Windows向けアプリの大半はそうだな。

2022/09/19(月) 13:09:05.53

仕様ではUTF-8と書いてあるだけ。ならばBOMの有無に関係なく読めるようにするべき。

2022/09/19(月) 13:13:10.64

仕様ではUTF-8と書いてあるなら、あったら読み飛ばせば良いだけだな

2022/09/19(月) 13:29:40.55

にも関わらずBOMがないとわざわざエラーを出して終わる

2022/09/19(月) 13:40:15.70

単なるバグだろ、とっとと直させろよ

2022/09/19(月) 14:03:09.97

> こういうやつ

BOMなしUTF-8のデータそのものを修正したいのか
BOMなしUTF-8のデータを読めるようにプログラムを修正したいのか
プログラムを作ったやつに復讐したいのか

どれだ

**ハノン** ◆QZaw55cn4c (US 0H7f-G1yF) · 2022/09/19(月) 15:32:18.43

BOM はもともと UTF-16 のためのものでしょう？
それを、UTF-8 に対しても無条件に BOM をつけてしまうウンコエディターを量産している奴等に問題があるんですよ…

また、正直にいって、規格で決めればいいとかいう思考停止にも我慢ならないんですよ
美しい世界（爆笑）のために今日もがんばります！

2022/09/19(月) 15:34:28.84

HTMLもBOM推奨してなかったっけ。

2022/09/19(月) 15:56:49.87

HTMLの場合、「BOM」付けると、PHP で謎の空白ができてしまうなど動作や表示に不具合が出る可能性があるそうです。

2022/09/19(月) 16:04:04.51

それは、BOM付けるのがPHPの仕事だからじゃないの？

2022/09/19(月) 16:20:33.07

PHPは中途半端に歴史が古いから、Unicodeといえば、UTF-16なんだよな。

でもそのおかげでWindowsとの相性は悪くない。

2022/09/19(月) 16:20:51.69

そもそも UTF-8 には、エンディアンの違いがなく、BOM（バイトオーダーマーク）を付ける必要がないんだそうだ

2022/09/19(月) 16:22:57.02

HTMLの場合はHEADに使っている文字コード情報が入っているのでそれを見れば良い事になる

2022/09/19(月) 16:25:44.76

>>264
たしか規格でBOMを優先することになってなかったっけ？

2022/09/19(月) 16:33:42.03

文字列としてバイトオーダーが実際に問われるのは、
UTF-16やUTF-32のケースだけです
その場合は必要ですね

2022/09/19(月) 16:34:41.81

確認したところ、なってたわ。
HTMLパーサー書いたことがあるから、おぼろげに覚えてた。

2022/09/19(月) 16:46:36.41

・BOMがある場合、BOMに従う。
・ない場合、500ms、あるいは1024バイト読み込むまで待機し、エンコーディング走査アルゴリズムを呼び出す。

エンコーディング走査アルゴリズム内で、ヘッダー内の情報が読み取られる場合もある。
（このアルゴリズムでも、他に優先される情報がある。）

やはり、HTMLにおいては、BOMをつけるべきだな。
読み込みが速くなるし、文字コードの違いを利用した攻撃を避けることが出来るし。

2022/09/19(月) 16:47:54.37

HTMLの場合は、HEADに使用するcharsetが記述されてますから心配ありません

2022/09/19(月) 16:48:57.21

昔の外国映画で「ふにゃちん野郎が！」という悪口があったよね。
今後は「BOM無し野郎が！」と言うことを提案いたします。

2022/09/19(月) 16:49:03.30

それにUTF-8にはバイトオーダーがありません

2022/09/19(月) 16:50:38.05

>>269
規格上、BOMのほうが優先される。
BOMがある場合、エンコーディング走査アルゴリズムは呼び出されない。
BOMをつけましょう。

2022/09/19(月) 16:52:03.62

BOMをつけないとセキュリティ上の問題がある。

2022/09/19(月) 16:52:15.94

付けたWebサイトをここで公開して下さい
楽しみにしています

2022/09/19(月) 17:25:06.78

すべてのUTF-8にBOMがついてたらSJISはもっと早く消えてくれたと思うんだよね

2022/09/19(月) 17:31:57.08

この話題は、BOMをつけましょうということで、良いのでは？

**ハノン** ◆QZaw55cn4c (US 0H7f-G1yF) · 2022/09/19(月) 18:02:53.27

>>276
違います
BOM を付けるべき正統な理由がある時には付け、特に理由がなく惰性で付けてるんだったらやめよう、です

2022/09/19(月) 18:05:47.85

BOMを付けていない人を見かけたら、注意して差し上げましょう。
ということで、良いのでは？

2022/09/19(月) 18:12:09.41

テキストファイルを開いたとき最初の三文字がゴミかどうかいちいち判断するの？
2つのテキストファイルを結合するときゴミをひとつにまとめる処理するの？
BOMという考えが誤りなんだよ

2022/09/19(月) 18:14:42.87

法令でBOMを義務付けるべきでは？

BOMが無かったら通報するみたいな。

2022/09/19(月) 18:15:00.74

Windowsの一部アプリでBOMがないと動作不具合起こすんだよ
Officeとか、Officeとか、その辺
この辺への思いやりが必要な時は付けてあげると良い