C言語なら俺に聞け 164

(新スレ立ての際上記コマンドを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言語なら俺に聞け 163
https://mevius.5ch.net/test/read.cgi/tech/1721137434/

---

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

>>694
OSは好きで選べるもんじゃないから、Linux上で開発しても結局最終的にはMinGWに頼ることにはなるよ

最終OSは発注者が決める

クロス開発しても動作確認 (テスト) をしないわけにはいかないのだし、 Windows 用のソフトウェアを作るという前提なら Linux 上でやる意味はそんなにないな。
以前の Windows はパッケージマネージャが駄目だったから環境構築が面倒だったけど今は scoop とかがあるし。

オレなんかが仮想環境利用するのは、
1台でサバクラ環境作れるからなんだわ

MinGWはWindowsでGCC使えていいよな

一応windowsで使えるgccはある

wsl でやるのが楽

MinGW の Min は Minimal の Min

実際には autotools などのツールチェインやパッケージマネージャと連携しないと使えるライブラリのビルドや利用がやりづらいので Cygwin や Msys2 などの環境内で MinGW を入れたほうが良いと思う。
WSL でも良いけど MinGW のために WSL を入れるのだとしたらちょっと過剰かもしれない。

Minimalistな、MSYSじゃねーんだからw
Minimal GNUじゃ表したい概念とちょっと違うだろうよ

Minimalist GNU for Windows
らしい

>>703
間違えてた知識教えてもらえて良かったじゃん
見たらお礼の一言でもあってもいいかもね

お礼は物の方が良いぞ
ここに住所と氏名を書いておけ

>>706
掲示板にそういうのを求めても意味はない

お札を送る

どこの神社が良いですか？

昔cygwinとかあったけどな

悪バグ退散！

>>710
神社に行って参拝してはならない

>>711
今もあるようだが
https://www.cygwin.com/

WSLは結局Linux仮想環境だからそこでビルドしたってそのままじゃWindows向けには動かせない
Linux側でクロスコンパイルするにしても、Windows側でコンパイルするにしても、MinGW-w64 UCRT64を使うのが王道

OS固有の機能を使ってないのであれば
Windowsでも動くんではないですか？

そもそも実行ファイルフォーマット (をメモリに展開するローダの仕様) がOS固有なので……
Linux だと ELF で Windows は PE

それはそうですね
言葉が不足しました。

DOS時代はハード固有の機能を使わければ（キーボードBIOS使わず標準入力関連コマンドを使う等）
同じ系列のCPU/OSの他ハード（PC-98/TOWNS/DOS/V）でも動くというのはあった。

OSというのは元々そういう互換性を狙って作られたものだった

UNIX 以降の OS はハードウェアの違いを吸収する仕組みがある程度はあるけど最初からそれを目的のひとつとしていたかと言うとちょっと疑問。
数十年前に雑誌 (おそらく UNIX USER だったと思う) の連載記事で読んだことがあるようなないような曖昧な記憶だから不確かだけど。

汎用機の世界でも、富士通がIBM互換を狙った理由はそれでしょう

奥さん優秀な方だよな

ヘ_ヘ
ミ・・ ミ
( ° )～

これでどうか？

　ヘ_ヘ
ミ・・ ミ
　(　°　)～

難しいな

　ヘ_ヘ
ミ・　・ミ
　(　°　)～

うーん・・・

2ちゃんねるの AA はＭＳ Ｐゴシックを前提にする習慣なので微調整が必要であればメモ帳でＭＳ Ｐゴシックを設定して微調整すべし。
各ブラウジング環境のフォント次第なのでズレない方法というのは無い。

質問者は
gccを使いたいのか
cygwinを使いたいのか
windowsを使いたいのか
はっきりさせるべき

OpenLDAPみたいなプログラムを作ってみたくて、はじめてのCを買ってきました。
何日位で作れそうですか？

半日

作るのは簡単
動くかどうかは不明

>>730
本の内容から作るとすれば、標準入出力と構造体、制御構文、ファイル入出力を学んだら原型動作が作成可能かと。
何日で作れるかは読本ペースと理解度、追加機能とそのために必要な追加学習次第

まずはポインタの習得が肝心だよ

ポインタの習得できたら、
次はなんですかね？

たとえばポインタについて細部を学ぼうとしたらメモリ管理とも型システムとも強い関連性があって、それらを無視して理解することはできない。
つまりひとつを完全に習得してから次の機能を学ぶなんていうきちんとした順序はつけられない。
そこをどうにかして上手いことわかりやするために入門書は腐心してるのでとりあえず一旦は入門書を最後まで読んで理解することに努めたらいいと思う。
こんなところで聞くより入門書の著者や編者の努力を信じるべき。
どうしても理解できない箇所をピンポイントで尋ねるなら掲示板も良いだろうけど本の体系的な説明のほうが全体としては良い説明になってるはずだよ。

おすすめ「苦しんで覚えるC言語」
サイトもあるけど、やっぱり本じゃないとね
古い本だから今更新品の本を買う必要なし、アマゾンで中古本をポチればいいよ

電子書籍で良いのでは

> おすすめ「苦しんで覚えるC言語」

サイト見たけど間違い結構あるなｗ

Geminiのガイド付き学習でインタラクティブに学習できるよ
そういう時代

質問が見当はずれだと回答もよくわからん。
Gemini に手伝ってもらうにしてもベースとしてはちょっとした入門書はあったほうが良い。

ちょっとした入門の、
範囲が知りたいんだが

> ちょっとした入門の、範囲

未定義動作を正確な知識により踏まなくなる程度

Z知能にCは無理
Rust知能にもCは無理

殆どの人はそれで十分だと思うよな

私が入門したのは何十年も前の話だから……その頃の感覚で言われても困るだろう。
C に入門するより先に機械語をいじっていたタイプの学習ルートを経ていて、私の同世代は少なからずそんなものだが明らかに現代的な学習ルートではない。

そんで分かってしまうといまさら入門書を見て良し悪しの評価なんかできない。
説明に間違いがあれば指摘はできるけど分かり易さは別の話だし、方便として多少の不正確さを許容したほうが良い場合もあるし。
おそらく入門書は教育者が実際に教育に使いながらフィードバックを重ねたものが良いものになるんじゃないかと思う。

す自動変数

すまん
自動変数を一杯宣言し過ぎてスタック破壊した経験ってないですか？

>>746
> 教育者が実際に教育に使いながらフィードバックを重ねたもの
＝大学の講義資料だろ
今ならStanfordやMITや東大からそこらの駅弁まで手に入る

>>748
コンパイル時に指定すればスタックサイズを増量できる

>>750
Windows だとスタックの上限は実行ファイル内に格納されるパラメータだからコンパイル時の指定で変えられるけど現代的 OS の一般論としては OS の側の設定値として持っているのが普通だと思う。
少なくとも Linux や BSD だとそうなってる。

普通はヒープ使うからなぁ

unix用のgccだとlinkerのオプションだったと思う。
ただ聞きたかったことはそう言うこたではなかったです。

ふん fixup overflow の呪いを受ければ良いんだ。 :-p
※開発中にこれを喰らうとデスマ確定のLINKエラーｗ

>>748
スタック領域の理解がない頃に謎の不具合として闘っていた可能性はある
大きな配列をmainに定義するとなぜか動かないとか、しかしグローバル変数にするとなぜか動くとか

>>755
さう、それです。
元々FORTRANで書かれていたプログラムを移植してました。
各ロジックの移植までは良かったんですが、
配列宣言が関数内に複数個、それぞれ要素数が数万個ありました。
最終的にヒープに取ることにしましたが、あまり納得はできなかったです。

>>756
それは移植戦略を間違ってる。
FORTRANなんてグローバル変数しかなく、
つまりローカル変数が無くて再帰も出来ない糞言語で、だからこそ廃れたわけだが、
C流のきちんとしたコードに直してやる必要が最初から無い。
まんま全部グローバルでも変数名が被らないのは元ソースが保証してるし、
Cのグローバルはファイル内スコープであり、externしなければ他ファイルからも見えないので、
ファイルを分けておけば他とも被らない。

ただまあ、それでも、スタックサイズを調整するのも一つの正しい方策だと思うけど。
実行時のフットプリントは同じだし。
ちな、FORTRANの移植時には多次元配列の格納順が違うからそこだけ注意な。
https://iifx.dev/ja/articles/457242272/%E9%85%8D%E5%88%97%E3%81%AE%E6%A0%BC%E7%B4%8D%E9%A0%86%E5%BA%8F%E3%81%8C%E6%8B%9B%E3%81%8F%E6%82%B2%E5%8A%87-c%E8%A8%80%E8%AA%9E%E3%81%A8fortran%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E5%8A%B9%E7%8E%87%E3%81%A8%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%AE%E6%88%A6%E3%81%84

>>753
> ただ聞きたかったことはそう言うこたではなかったです。
死ねよクソZ。
お前らは全て他責なのが駄目だ。
「FORTRANからの移植時に」とお前が最初から言えば回避出来た話だろ。

>>751
> 現代的 OS の一般論としては OS の側の設定値として持っているのが普通
Linuxではulimit -s で変えられるらしいが、どっちが「普通」かには異議ありだな。

そもそもそのプログラムがスタックを大量に消費することはプログラマしか知らない。
だからコンパイル時にマークしておく必要があり、その上で、
システム側で許容された値以下なら許可する、という方式が正しいだろ。
Linux方式だと、エラーになったらその都度対応してくれ、ただどれくらい必要なのかは知らん、というマヌケな事を強制する仕様ではないか。
exeに明記されてれば、少なくとも、静的に大量確保される場合は完全に対応できる。今回もそうだろ。
Windowsの仕様のほうが「普通」で「正しい」と俺は思うね。(よりマシな仕様)

>>757
今のところ、科学技術関連のソフトウェア資産はFORTRANの方が多いし、
研究者が書くプログラムも殆どがFORTRANだよ

>>759
お前が頭おかしいのは分かった

>>757
>Cのグローバルはファイル内スコープであり、externしなければ他ファイルからも見えないので、
ファイルを分けておけば他とも被らない。
ここで判断すればオケ

>>761
引用されるまで気にしなかったけど
ファイル内スコープ(内部結合)にしたければstaticを付けてください
staticを付けない広域変数はextern参照されなくても外部結合なので、複数のファイルで同名の定義を行うと多重定義となってリンクができない

> Cのグローバルはファイル内スコープであり、externしなければ他ファイルからも見えないので、

初期化子を書かない仮定義かなんかを誤解してる希ガス

2000年頃にやったプロジェクトでC/C++対応ヘッダに
Cコンパイラでは
int c;

C++コンパイラでは
extern int c;

となるように書かれてたな。

>>764
Cの場合、そのヘッダーを複数Cソースでインクルードするのはまずくないですか？

>>765
なんかまずいことあるんですか?
https://wandbox.org/permlink/Yr1oe28UFqBSu0hh

#ifdefの類いを使わないでやってみて

> #ifdefの類いを使わないでやってみて

こうですか?
https://wandbox.org/permlink/EskOFaZWlK4yeyFe

普通はヘッダファイルにゃ変数宣言書かないやろ

> 普通はヘッダファイルにゃ変数宣言書かないやろ

じゃあこうかな
https://wandbox.org/permlink/rWNB2Zsj6Kft3dfP

変数を直接には公開しない (適当な関数を通じてのみアクセスする) のでヘッダに書くことはないという意味じゃないの？

>>770
構ってちゃん死ね

グローバル変数は限定的に使おうね

>>770
>>762を書いた者ですが、コード内容を調べ、書き方次第で多重定義エラーにはならない事が分かりました。誤情報を書いてしまい失礼しました

C言語では「int c;」と書いた場合は外部変数定義のように見えて実は仮定義という扱い、「int c = 0;」と書いた場合が定義扱いなのですね、、、
仮定義には、定義があればそれを参照できるように機能し(関数宣言に近い動作ですね)、定義がなければ仮定義をもって具象化行う働きがあるのですね

一方C++はODRの厳格化を進めたことによりルールが変わっているようで、私はそれと混同していました

>>774
お前も混乱を増長させるな
コンパイラのバージョンを確認してみろ、ゆとりＺがよくやる手口だ

$ gcc --version
bash: gcc: command not found

> コンパイラのバージョンを確認してみろ、ゆとりＺがよくやる手口だ

gccのバージョンを新しくしろと言ってるのかな?
https://wandbox.org/permlink/lSFKJiRf1Yr0CX0Y

>>775
私の言葉ではかえって混乱を生むかもしれませんのでソースを貼っておきます

https://ja.cppreference.com/c/language/extern

検索には「C言語 Tentative definitions」等も有効です。
C89の頃から存在する挙動、C99で明文化されたようです。

変数と関数で、宣言、定義のルールなんか変わるかな？

つい最近に仮定義の話題をどこかで見た覚えがあると思って記憶をたどると Qiita に記事があった。
https://qiita.com/TETSURO1999/items/649b033975583750ad20

C と C++ は世間で思われているよりも多くの非互換をかかえていて、表面上の構文が同じにもかかわらず挙動が違うなんてのは割とある。
C++ に慣れていると C の inline の挙動にびっくりしたりする。

非互換と言うより別物と捉えた方が良いと思う

でもC++のコンパイラでCもコンパイルできちゃうからなぁ

C と C++ がそれぞれ独立した規格なのは確かなんだけど離れすぎないように配慮はしているんだよ。
配慮した上でこれ。
まあ C の変なところを C++ でもやれとは言えないし、 C はその性質から保守的なのも仕方なくはある。

VC++でC++ソースをコンパイルしたらエラー出て、なんでかなぁと思ったら拡張子が.cだった初心者時代・・・。

C の宣言の文法があまりにひどいので C++ で変えるべきかどうか迷ったという話が D&E に載ってる。
結果的には C を踏襲することにしたけど、変える決断をしていたらかなり大きくプログラミング言語史が違っていたかもしれないな。

C++の良いところは
取り込んでいっても良いと思います。
オプションで良いです。

>>786
今のgccは互換を保つためのオプショナルのようですね。
-fno-common が規定値
-fcommon は>>777のように指定が必要

>>780
>C++ に慣れていると C の inline の挙動にびっくり
ほんそれ

なれようず

C標準も見た目だけC++に寄せてくるしなー

秋来ぬと
目にはさやかに
見えねども
風の音にぞ
おどろかれNULLポ

そよぐとも目には見えねど白露の宿れる草に秋は来にガッ

C言語の内容とは関係ないんだけど、古い入門書の「まえがき」に、
「言語とは、筆者が言っていることを理解し、読者が筆者の言わんとすることを理解しようとすれば、その役割を果たす。」
みたいな事を書いていた書籍のタイトルと著者がわかる人おる？

お探しの書籍は、林晴比古（はやし はるひこ）氏による著作『C言語入門』（ソフトバンククリエイティブ／ソフトバンク出版）シリーズである可能性が極めて高いです。
林晴比古氏のプログラミング入門書（『C言語入門』や『BASIC入門』など）の「まえがき」には、プログラミング言語の本質をコミュニケーション（意思伝達）になぞらえた印象的な記述があり、以下のような趣旨の文言が記されています。
「言語とは、話者が言いたいことを表現し、聞く側（読者）がその言わんとすることを理解しようとすれば、それで十分にその役割を果たすものである。」
（※プログラミング言語も同様に、文法に捉われすぎず『コンピュータに何をさせたいか』という意図を伝えることが本質である、という文脈で語られています）

該当する可能性が高い書籍
書籍名： 『明解 C言語 入門編』または『新・C言語入門 シリーズ』（旧・『C言語入門』）
著者： 林 晴比古（はやし はるひこ）
出版社： ソフトバンク（SoftBank Creative）

著者の特徴と文脈
林晴比古氏は1980年代〜1990年代にかけて数多くのC言語やPascal、BASICなどの入門書を執筆されたPC黎明期のベストセラー著者です。
同氏の入門書の「まえがき」や「はじめに」では、次のような哲学が繰り返し語られていました。
単なる文法チェックや構文暗記に囚われないこと
「人間とコンピュータ（あるいは筆者と読者）」の間で意図や論理が正しく伝わることこそが「言語」の本質であること
もし昔読まれたC言語の緑色や青色の表紙の入門書（ソフトバンク刊）であれば、林晴比古氏の書籍で間違いありません。一度表紙や著者名に見覚えがないか確認してみてください。

AIの答えか
つまりAIは書籍を学習してると

林晴比古とか三田典玄とか昔の評判悪かった著者懐かしいな