C言語なら俺に聞け 157

2021/06/28(月) 11:22:51.50

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.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言語なら俺に聞け 156
https://mevius.5ch.net/test/read.cgi/tech/1601271690/

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

2021/09/14(火) 07:26:42.56

よかったね

2021/09/14(火) 09:36:35.35

卒論のテーマはこれで決まりだな

2021/09/14(火) 10:50:21.10

アドレス私って、
b = a;
c = a;
とかやってて、a=0にすると、bもcも0になるってこと？

2021/09/14(火) 11:31:36.84

それは参照だ
C++のな

Cでやるなら
#define b a
#define c a

2021/09/14(火) 13:58:37.43

>>557
Matz の論文は I hate C++ だぞω

2021/09/14(火) 15:48:56.00

>>556
性能重視の部分は考え方の違いだな。UNIXを作るにあたって不要な部分を取り除いた結果がC。

2021/09/14(火) 15:51:55.83

>>560
メモリのアドレスを直接、渡すから、呼び出し元の領域をそういうふうに直接、触ることになる。

**ハノン** ◆QZaw55cn4c · 2021/09/14(火) 17:38:29.69

私は pascal は好きなんですけど‥‥

2021/09/14(火) 23:42:22.10

Delphiは昔使ってたな。拡張しまくったPascalというかなんというか。

2021/09/15(水) 00:41:20.00

アセンブラのようなことができた方がいいというのが出発点だからなあ

2021/09/15(水) 01:36:14.40

今でこそ C は低レイヤ寄りと見做されるけど「高級言語で OS を書きたい」というモチベーションから作られている。
おそらく当時の感覚からすればむしろアセンブラ的な世界からの脱却だったんじゃないかな。
歴史的経緯はある程度は記録を辿れるけど時代を背景にした「感覚」というのは現代人からはなかなか掴みづらくてあくまでも想像だけど。

2021/09/15(水) 05:11:14.87

おおざっぱに言うとアセンブラの見た目を変更したのがC

2021/09/15(水) 07:08:27.66

アセンブラの無駄のなさと、高級言語の移植性の、両取りを狙う試みだね

**ハノン** ◆QZaw55cn4c · 2021/09/15(水) 14:05:30.69

それはどうでしょうか‥
turbo c の asm 文抜きのいきなりインラインはよく使っていましたが、そんな turbo c でもキャリーフラグを直接使えなかった気がします、そんな記憶がふつふつと

2021/09/15(水) 14:16:20.72

ローテート命令はキャリーありの9bit循環とキャリーなしの8bit循環があるから
そこまで言語では面倒見きれなかったってだけ
ステータスレジスタを陽に記述すると移植性なくなるが
そんなことしなくても当時のUNIXの95%を記述できたしな

2021/09/15(水) 15:25:36.81

#ifdef flagresister取得可能(ならば)
専用式
#elseif
~

2021/09/15(水) 15:31:31.69

みたいな専用式を言語仕様に含めたやり方も出来たかもしれん
当時の演算能力内でwrite once,RA かつアカデミック感目指してomit しちゃったんかな

2021/09/15(水) 16:26:01.26

Keep the language small and simple.

2021/09/15(水) 17:05:05.53

>>571
そもそも世の中にはキャリーフラグなんてないプロセッサもあるから
俺の知る限りキャリーフラグを扱える高級言語はTL/1しかない

**ハノン** ◆QZaw55cn4c · 2021/09/15(水) 17:16:31.92

>>576
そうなんですね、なんちゃって多倍長をやっていて、ここでローテート＆キャリーが使えればなぁぁぁ、とつくづく

2021/09/15(水) 17:52:22.20

>>576-577
TL/1 はあくまでも演算子がキャリー/ボロー付き演算の命令にそのままコンパイルされるってだけなんで、
配列アクセスなどのときに勝手にアドレス計算でフラグが設定されてしまうといった意図しない影響があって
あまり使い勝手は良くない。

あまり詳しくないけど LLVM はキャリーフラグを扱う方法があって
かつレキシカルな伝播として記述できたはずなんで、
たぶん LLVM IR でならなんとか記述できるんじゃないかな。
LLVM IR を高級といえるかどうかはたいへん微妙な話だが……。

2021/09/17(金) 10:00:39.91

>576
https://www.zukeran.org/shin/d/2015/04/10/kumajiri-compiler/

2021/09/17(金) 10:32:07.44

>>578
例えばこんなを高級言語って言う？
define i32 @main(i32 %argc, i8** %argv) #0 {
%1 = alloca i32, align 4
%2 = alloca i32, align 4
%3 = alloca i8**, align 8
store i32 0, i32* %1
store i32 %argc, i32* %2, align 4
store i8** %argv, i8*** %3, align 8
%4 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([15 x i8]* @.str, i32 0, i32 0))
ret i32 2
}

>>579
ごめん、意味分からん
単なるVTL (Very Tiny Language) の話にしか見えない

2021/09/17(金) 14:21:22.00

>>580
rustよりは高級に見えるな

2021/09/17(金) 14:42:13.05

>>580
そこから様々なターゲットの機械語を生成しうるという意味では
ハードウェアにベッタリと紐付いているわけではなくて
LLVM IR を低水準言語と呼ぶのはなんか違うなって思うけど、
だからといって日常的に人間が直接書くことを前提においてるわけでもない
という点では高級とも言いにくいかな……という意味で「微妙」と評した。

2021/09/17(金) 16:26:05.73

シリコンバレーで働いて気付いた「技術力向上」だけに固執するエンジニアのダメさ【Sansan CTO 藤倉成太】
https://type.jp/et/feature/9402/
DeNA×メルカリ×サイバーエージェント人事担当が面接で必ずする質問とは？「技術力だけアピールしても内定は出ない」
https://type.jp/et/feature/10236/
DeNA・メルカリ・CA人事が証言！スキルはあるのに“面接で落ちる”エンジニアに足りないもの
https://type.jp/et/feature/10402/

2021/09/17(金) 20:48:41.30

>>582
> そこから様々なターゲットの機械語を生成しうるという意味では
> ハードウェアにベッタリと紐付いているわけではなくて
Javaのバイトコードを高級言語って言うの？

2021/09/17(金) 20:59:27.14

>>584
JVM のバイトコードは言語ではないと思うから高級言語とは言わないけど、低水準でもないでしょ。

2021/09/17(金) 21:50:22.49

低水準の話はしてないから
> 高級言語とは言わない
でFAやね

2021/09/17(金) 22:00:48.37

そうか。

2021/09/17(金) 22:31:46.08

C言語だってコンパイルすればバイナリ

2021/09/18(土) 04:33:04.80

倍也

2021/09/18(土) 08:52:55.38

バイトコードをいい加減に扱い過ぎ

2021/09/18(土) 09:19:07.92

>>580
特定CPUのアーキテクチャに言及してないな

2021/09/18(土) 18:56:12.62

宣言と定義についてなんですが

int a; // 宣言
int b = 1; // 定義

宣言と定義ではどちらもメモリ（スタック）は確保されているという理解であってますか？

2021/09/18(土) 19:10:22.14

はい

2021/09/18(土) 19:28:32.87

はいじゃないが

2021/09/18(土) 19:42:16.97

>>592
変数宣言のうちメモリを確保するのもが定義。
その２つは両方とも宣言であり定義でもある。

2021/09/18(土) 19:43:03.59

コンパイラと最適化オプション次第

2021/09/18(土) 19:48:26.79

>>595
定義は宣言の下位概念ってことですか？

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 9f47-o3tO) · 2021/09/18(土) 19:55:00.96

>>592
いいえ
定義では格納場所を確保しますが、宣言では存在のみ指示しても格納場所は確保されません、私は気が向けば宣言には extern をつけるようにしないわけではない、という感じかな
なおその例は少し変で、代入を伴えば定義というわけでも、代入がなければ宣言というわけでもない、というのが個人的感覚です、詳しい人の解説を希望します

例外は、リンカが頑張って格納場所を作ってくれる例の何とかとかいうキーワードがあったのですがおもいだせません、今日モデルナを射った後転んで頭を打ってしまった、結果、いっそう馬鹿になってしまいました‥‥

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 9f47-o3tO) · 2021/09/18(土) 20:04:32.98

>>592
宣言か定義か、という問題は、単一モジュールでプログラムを構成している段階ではあまり気にしなくてもいいと思います
複数の c ソースを分割コンパイルし、最後に得られたオブジェクトをライブラリともあわせて結合する、という作法に進めば自然に理解できるようになりますのでご心配なさらなくともいいでしょう

私も昔は「extern は要らない子！」とか馬鹿をいっていましたが、これは撤回します、extern がどうしても必要な場面に遭遇したのです
まあそういうわけで一度にいっぺんに賢くなるのは私には難しいことのようです

2021/09/18(土) 20:41:39.21

>>598
たとえば

int a;
printf("%d\n", a);

なんですが、この場合のaは定義されているということですか？
代入式があるのが定義だと思ってました
宣言と定義の文脈はコードによって変わるということなんですかね

2021/09/18(土) 21:25:06.90

簡単に言えば宣言はその名前をコンパイラに伝えるもの
定義はその実体を確保するためのもの
>>592の例は両方共に宣言であり定義でもある
C言語では定義のみすると言うのはできないと思う
宣言のみはexternとか前方参照のためのstruct xxx;とかで使われる

2021/09/18(土) 21:44:48.00

>>596
屁理屈こねんなやボケが

2021/09/18(土) 22:06:39.93

..>>597
「下位概念」という言葉をあてるのは不自然な気がするけど、C言語において定義は宣言のサブセットだよ。

>>600
その２行がコンパイルできる文脈に置かれているなら、 a は定義されている。
（初期化されていない自動変数になるので後続の printf での読み取りは未定義動作になるけど。）
「宣言と定義の文脈はコードによって変わる」は意味が分からないので否定も肯定もできない。
同じ int a; といった記述が宣言か定義か文脈によって変わる、ということならありえる。（構造体メンバの宣言とか。）

2021/09/18(土) 22:22:54.90

>>601
>>603
メモリが確保されているかどうか？という点で定義か宣言か判断すればいいということですね
printf()で参照している場合はaはメモリが確保されているのでaは定義されている状態
printf()で参照しない場合はaはただの宣言になると

2021/09/18(土) 22:32:01.92

>>604
レスの後半はいらないよ
参照されるか否かは関係ないよ

int a;
で定義は完結してるから

2021/09/18(土) 22:36:06.58

>>604
> printf()で参照しない場合はaはただの宣言になると
違う、参照の有無に関わらず領域は確保される
最適化とか鼻から悪魔のコードだから確保を端折るとかはあるけどそれはまた別な話

2021/09/18(土) 22:53:55.61

>>605
>>606

理解しました！

int main(void) {
int a;
return 0;
}

↑のaは定義されていてメモリが確保されている状態ってことですね
また定義は宣言のサブセットだから、この状態を宣言と呼んでもいいということですね

2021/09/18(土) 23:32:59.41

aは定義されている、でよいと思います
ちなみに、自分は宣言とか定義とか「言葉」は意識しないです
ただ、ここにオブジェクトが実在するのか、他のどこかにあるオブジェクトを使うのかは明確に意識しなければなりません

int main(void) {
int a;
extern int x:
return 0;
}

ここで xは、関数外のどこかで定義された int型のオブジェクを参照します、という宣言

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 9f47-o3tO) · 2021/09/18(土) 23:37:35.98

>>607
そうですね
それに、そのコードは関数 int main(void) も宣言かつ定義していますね
関数の場合は、関数の中身が書いておれば宣言かつ定義、関数の呼び出され方だけしか書いていなければ宣言、とすぐにわかるので、キーワード extern は省かれる傾向にありますね

詳しい人に解説いただき私も感謝します

2021/09/18(土) 23:38:56.69

質問
externを関数内で宣言したとき､有効範囲は次のどれになりますか？
1．宣言した関数のスコープ内で有効
2．宣言したソースの後続行で有効
3．宣言を書いたソースの全体で有効

2021/09/18(土) 23:43:44.98

A.1

2021/09/18(土) 23:45:59.85

通常の変数と同様に、ブロック {} で括られるかと

2021/09/19(日) 00:58:34.79

JISX3010:2003 の 6.7 から抜粋

> 宣言は、幾つかの識別子の解釈及び属性を指定する。
> 識別子の定義 (definition) とは、宣言のうち次のものをいう。
> ・オブジェクトに対しては、そのオブジェクトの記憶域を確保する宣言
> ・関数に対しては、関数本体を含む宣言
> ・列挙定数又は型定義名に対しては、その識別子の（唯一の）宣言

2021/09/19(日) 12:56:33.95

関数の中とか{}ブロックの中とかで
#include とか #define 出来れば良いのにと思うことはある
(いや出来ることは出来るけど)

2021/09/19(日) 14:00:14.49

>614
その辺は古い仕様の限界だから……

2021/09/19(日) 14:08:34.86

>>614
便利だよね
CSV埋め込みとか

2021/09/19(日) 15:49:36.39

>>610
>>611
2だったような
1の方が合理的だが

2021/09/19(日) 16:19:30.05

// foo.c
#include <stdio.h>

int f(void)
{
extern int glob:
return glob + 1;
}

int main()
{
printf("%d\n", f()); // 124(次行がないとき)
printf("%d\n", glob); // エラー
return 0:
}

// bar.c
int glob = 123;

でした
勘違いだったらごめんなさい

2021/09/19(日) 16:24:53.88

int f(void)
{
__{
____extern int glob:
__}
__return glob + 1; // glob undeclared
}

2021/09/19(日) 18:52:30.28

extern の変数をスコープ内に書きたい場面ってあまり思いつかない。
ヘッダファイルに書くのサボりたい時くらいしかそんな書き方しないな～

2021/09/19(日) 19:48:44.86

>>620
>>608だけど、(関数スコープ内の)宣言のうまい例を思いつきませんでした
自分でもこのような記述はしたことがないです

>>614
ブロック内でも、#includeや#defineは使えるには使えるのでは
使ったことはないけど
ただし、#defineは同じスコープ内で #undefで閉じておかべきだけど
リーダブルコードという本で、define～undefの例を見たような

2021/09/19(日) 19:52:36.17

>>620
俺はそのスコープでしか使わないなら普通にスコープ内に書くけど？

**621** (ｱｳｱｳｳｰ Sa5b-XGHE) · 2021/09/19(日) 20:02:10.63

>>614
「できるにはできるけど」と、ちゃんと書いてありますね
大変失礼しました、ごめんなさい!!

2021/09/19(日) 20:34:55.88

ひょっとして、#define も関数内で記述すると
そのスコープ内で有効になるのかな？

2021/09/19(日) 20:40:54.81

>>624
流石にそれはない。

**621** (ｱｳｱｳｳｰ Sa5b-XGHE) · 2021/09/19(日) 20:42:46.70

#includeとか #defineとか、プリプロセッサが処理する時点では、スコープとか、C言語の文法すら関知しないかも
トークンの
識別くらいで

2021/09/19(日) 21:23:46.86

こんな #define 見たくないけど・・・

---------------------------------------
void func() {
　#define A 100
}
int main() {
　int i = A;
}
---------------------------------------

gcc -E prepro.c
---------------------------------------
# 1 "prepro.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 384 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "prepro.c" 2
void func() {

}
int main() {
　int i = 100;
}
---------------------------------------

2021/09/20(月) 10:14:32.45

Cにnamespaceが無いのが逝けない娘

2021/09/20(月) 15:37:40.46

いらねぇだろネームスペースなんか

2021/09/20(月) 16:28:35.49

namespaceが欲しいのにC++を使わないのが逝けない娘

太古の昔、Cにクラスが無いのが逝けない娘だと思った人とは行動力が違いすぎるな

2021/09/20(月) 17:39:30.67

CはCのままで良い。他の言語で実現出来ているんだし。その機能を使いたいならそちらの言語を使えば良い。
それでは何かが足りないというのなら新言語作れば良い。
自分では作る技術力がなくても仕様を考えてネットで公開しておけばやがて暇と技術力のある誰かが作ってくれるだろう。

2021/09/20(月) 18:06:11.00

>622
型を間違えてもエラーにならないから全くお勧めしない

2021/09/20(月) 19:39:36.63

>>632
はあ？
何言ってんの？
頭大丈夫？

2021/09/20(月) 19:50:34.34

ミスする可能性が上がるから各コードでexternせずに必要ならヘッダに書いてもらえってことじゃね？

そもそもexternなんてextern "C"以外滅多に使わないけどな

2021/09/20(月) 19:57:31.48

>>633
前スレより

975 デフォルトの名無しさん (ﾜｯﾁｮｲ b363-19dE) sage 2021/06/21(月) 23:06:35.04 ID:jHz8GYW10
// b.c
int b[] = {123, 456};

// a.c
#include <stdio.h>

int a[] = {123, 456};
int main()
{
　　extern int *b;
　　printf("val b\n");
　　printf("%d\n", *(b + 1));

// printf("val a\n");
// printf("%d\n", *(a + 1));

　return 0;
}

こういう分割ソースをコンパイル、リンクして実行すると、何も表示無しで終了する
デバッガー使って実行してみると、SEGVになってる

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 9f47-o3tO) · 2021/09/20(月) 20:10:17.55

>>634
＞ミスする可能性が上がるから各コードでexternせずに必要ならヘッダに書いてもらえってことじゃね？
そうそう、extern による宣言と定義とが食い違うとエラーがでますから、そのためのヘッダの分離ということですね

＞そもそもexternなんてextern "C"以外滅多に使わないけどな
関数の宣言は extern 省略可能ですし、ライブラリ側で共用のメモリを確保することは滅多にないです私は

**621** (ｱｳｱｳｳｰ Sa5b-XGHE) · 2021/09/20(月) 23:40:17.11

>>635
これは関数のスコープに書かなくても(ファイルスコープでも)同じじゃない？

**621** (ｱｳｱｳｳｰ Sa5b-XGHE) · 2021/09/21(火) 00:23:33.65

>>635
これってリンク時にエラーにする方法はないのかね….
あればとっくにやってるんだろうけど…

2021/09/21(火) 00:26:56.39

>>637
同じですね

そもそもexternを明示的に書く必要がある状況って、
あるソースで定義されているグローバル変数を他のソースに公開して使えるようにするために、
ヘッダにextern int a;のように書いておいて、他のソースにはそれを#includeさせる
（すると他のソースでは余計な領域が確保されない）
のパターンが基本だと思っています

だからそもそもブロックスコープでexternするのってなんで？覗き魔？って思ってしまう

2021/09/21(火) 03:22:03.74

ブロックスコープ内でexternはK&R C時代の名残で今は完全に無意味

2021/09/21(火) 03:23:48.34

関数原型でのexternは単項プラスみたいなもん
staticじゃないよと強調する反対語

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 9f47-o3tO) · 2021/09/21(火) 03:36:19.96

>>639
＞ヘッダにextern int a;のように書いておいて、他のソースにはそれを#includeさせる
「他のソース」でないソースも、そのヘッダを #include しておけばダチェックにもなるし

2021/09/21(火) 19:14:32.01

>>639
ヘッダに実体がある糞コードで
でも直すなって言われて仕方なくexternすることはあった

**621** (ｱｳｱｳｳｰ Sa5b-XGHE) · 2021/09/21(火) 22:41:16.78

// b.c
char a[] = { 0, 1 };

// a.c
int main()
{
__extern int *a;
__printf("%d\n", a[1]):
__return 0;
}

不勉強でした
上のコードは警告もなしにコンパイルが通りますね
実行すると segmentation fault ですが

リンク時はデータ型はチェックされず、名前だけで参照を解決してるのですかね……

古い仕様で、今さら変更はできないんでしょうね、チェックができたとしても

2021/09/21(火) 22:46:25.12

型システムを持たずラベルの綴りのみを手がかりに参照解決するリンカを操るツールの１つだからねCは
リンカにあれもこれもと機能を持たせるのはメインフレームのファイルシステムにあれもこれも持たせようとしたVSAMの再来だ
インフラ的なものにアプリの都合を無闇に押しつけるべきではないことを歴史から学ぶべきだぞ

2021/09/21(火) 23:19:06.05

C には「プロトタイプ (関数原型) を持たない関数宣言」があって、
関数の型が曖昧なまま関数が存在することだけを宣言できる。

プロトタイプ (プロトタイプ宣言) がある場合にはその関数を呼出すにあたって実引数と仮引数の間では代入と同じ規則
で (可能な場合には) 暗黙の型変換が適用されるが、プロトタイプがない場合には
既定の実引数拡張 (可変長引数に実引数を渡すときと同じ規則) が適用されて実引数と仮引数の辻褄が
あってないときは未定義という扱いになる。

更には C89 は暗黙の関数宣言という規則があって (C99 では廃止されている)
関数を呼出そうとした時点で関数が宣言されていない場合には実引数の型から一定の規則に基づいて
関数の型を推測し、関数が宣言されたかのように振る舞うことになっている。
なので関数宣言が存在しなくても二度以上の関数呼出しの型に矛盾があれば検出はされる。
もちろん関数定義の実体と辻褄があってなかったらそれは未定義だけど。

このあたりのクソみたいな規則は「C++ では採用しなかった仕様」として D&E でちょっと触れられてる。

2021/09/21(火) 23:25:07.21

> 実引数の型から一定の規則に基づいて関数の型を推測し

func(1);
↓
int func();

func("string");
↓
int func();

こうなるだけで推測なんて気の利いたことはしないよ

**621** (ｱｳｱｳｳｰ Sa5b-XGHE) · 2021/09/21(火) 23:27:49.11

プロトタイプ宣言は C++からの逆輸入だからな….
その昔の Cったら

2021/09/21(火) 23:34:12.47

>>647
あ、ほんまやな。
仕様上のルールは「extern int func(); が書かれていたものとみなす」というだけで、
具体的なチェックをどこまでするかは処理系次第 (たぶんあまり真面目にやってなかったと思うけど) だな。

2021/09/22(水) 05:28:22.60

>>648
> プロトタイプ宣言は C++からの逆輸入

そうなの?

2021/09/22(水) 14:25:23.40

どうだったっけなあ？

2021/09/22(水) 14:32:16.52

The C programming language (いわゆる K&R 第一版) の
APPENDIX A 8.3 Declarators を見る限りでは
引数リストが空の形式しかないように見える。
関数であるということは宣言できるが型チェックはガバガバっぽい。

D&E の 2.6 静的タイプチェックの項では

> C with Classes のシンタクスとルールはその後 ANSI C の規格にも採用されたが
> C with Classes の最初の実装の時点ですでに完全な形をしていた。

という一文があるので C の型チェックは C++ (の前身である C with Classes)
からの影響ということで間違いないと思う。

2021/09/22(水) 14:42:52.46

初耳だわ
はちみつは何歳？

2021/09/22(水) 15:34:35.81

47歳くらいだと思う

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 9f47-o3tO) · 2021/09/22(水) 17:51:09.10

>>644
そのコード、仮に a.c で
extern int *a;
ではなくて
extern char *a;
であってもセグフォが出ると思います、試してませんけど‥‥

なにか二重に勘違いしてませんか？それとも私が二重に勘違いしているのか？

2021/09/22(水) 18:02:31.76

>>655
配列として定義したものをポインタとして宣言するのは間違いだな。

2021/09/22(水) 18:04:06.47

FAQ に書いてあったわ。
http://www.c-faq.com/aryptr/aryptr1.html