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

むかーーーし、rmsが『仕様より動くことが大事』みたいなこと言ってたのうっすら思い出した。
GCCって、ANSIで定義される前から1行コメント使えたよね。
とは言えGCCとてCである事を辞めていないと言うレベルの話だろうけど。

連投長文は内容以前に知能障害のバカ

>>654
反論できないから必死こいて罵倒しようという魂胆が透けて見えてる

>>653
多分勘違いしてると思うので言っておくと、未定義動作は本来なら動かない例だぞ

>>653
その発言は知らんが、仕様はあくまで手段であって、目的ではないからな。
とはいえ、その時代の価値観を今に持って来ていいわけはない。
仕様準拠の方がコミュニティ含め長期的な生産性は上がるのは確実。

ただ実際は、それとは程遠い。
JSは現実的に唯一、「ソースコードでの品質を担保」出来てる(させられてる)環境だが、
プログラマは実行環境の差異に振り回され、
IE死ね、次にFirefoxも死ねで、chromeに統一されることを望んでいる。
他言語は、RustにしてもC#にしても、主たる環境でのコンパイル結果でテストしており、
仕様準拠なソースコードならあらゆる環境で動作するとは言い難い。
Javaも元祖"Write Once, Run Anywhere"だが、実際は"Write Once, Debug Everywhere"になった。

本質的に、プログラマは、「自分と(ユーザー含めた)他人が同じ環境」が一番楽なのでこれを望む。
コンパイラ別のオプションや#ifdefなんて、コンパイラを固定してしまえばそもそも不要となり、
生産性を上げるためには環境を絞ったほうがいい。
ただこれでは永遠にソースコードでの品質は確保できない。
(たまたまその環境で動作するコードが出力されてるのをテストしてるだけになる)

この点、仕様と実装がデタラメに運用されてるC言語のほうが、
主たる環境もgcc/Clang/VC/各社勝手コンパイラと多種多様であり、
結果的にあらゆる環境でそのコードがコンパイルされ、テストされるので、
まだ「ソースコードでの品質を担保」に近いというのは皮肉だ。

>>653
ついでに言うと、C言語は「生産性を上げる為に仕様を絞る」事もやろうとしてない。

仕様準拠は主に(長期的な)生産性向上の為（＝ソースコードの品質を上げる為)として、
生産性を上げる為には仕様内の差異を潰す(仕様を絞る)事をしないといけない。
逆に言うと、仕様準拠だが実装がバラけるような「ユルい」仕様では意味がない。

具体的には、funcD(funcA(),funcB(),funcC())に対し、
C#やJSではABCD順に評価されると仕様で「固定」されているが、CではABC間は順序が規定されてない。
だから、この点、仕様準拠でも、たまたまABCD順の出力もあれば、BCAD順の出力もありえ、
その環境の「実行コード」をテストして動いたとしても、その「ソースコード」が正しいとは言えず、
本来は3P3=6倍の手間を掛け、「全順序ケースの『実行コード』」をテストするしか無いが、
現実的に、これが出来るコンパイラもない。

この辺、当たり前だが後発言語は潰してある。
Cでこの仕様を修正できない理由は、政治であり、(560参照)
コンパイラ作成側が1mmも譲らず、あらゆる自由度を最適化余地の既得権益としてるからだが、
これでは「何のための仕様なのか」であり、完全に本末転倒になっている。
(がまあ、これ含めてCの文化ではあるが)

なのでまあ、C界隈は、仕様準拠して生産性を上げるぞ、なんて目指して無くて、
昔から変わらず、自分環境で自分の希望するコードを得るための手段、となってる。
(勿論、仕様準拠ゴリゴリもありだが、Cの場合はそうやっても生産性が上がるようにはなってない。
《でもやらないよりはマシだが》)

ちな、同様のは、例えばJSではsortが不安定ソード→安定ソートに仕様変更された。
てか、他言語はちまちまこの辺を修正してるのだから、Cも修正しろよなと。
Cは変わらなすぎなのが問題。

本来、良い仕様を策定することはすごく難しくて、
あんまり「仕様」にこだわりすぎると前に進めなくなるので、ある程度諦めて「動くコード」をさっさと作れ、
とRMSは言ったのではないかと思われるが、
時代は下り、ソフトウェアについての知見も溜まってきてるので、今は仕様にもこだわらないといけない時代ではある。
(ただまあ、個人的にはRustではないな、と見てる。あれはゴミだ)

> funcD(funcA(),funcB(),funcC())に対し、
> C#やJSではABCD順に評価されると仕様で「固定」されているが、CではABC間は順序が規定されてない。

呼び出し順一意にしたかったらそういう書き方するだけだし、それ以前の話として「副作用ある式を関数の引数にすんな」くらいのコーディング規約は決めてて当たり前。

>>660
それは「対策出来る」だけであって、「あるべき仕様」ではないでしょ。
そもそもこの仕様を変更したとして、誰にも何らデメリット無いのだから、
コーディング規約によるアナログ対策ではなく、文法化で100%厳守強制でいい。他後発言語はそうしてる。
(地雷原で「旗立てといたから踏まないでね」と言われたら、いや「除去しておいてくれ」と思うでしょ)

Cはこの辺のノウハウが溜まる前の言語だから、色々仕様に不備があるのは致し方無しだが、
改善しようともしてないのは問題だと思うよ。

とはいえ結局、コンパイラ言語の成果物の最終配布形態/テストターゲットはバイナリであって、ソースコードではないから、
「このソースコードは動作します」なんて事はそもそも出来ないけど、
それでも一応、そこを目指すべきではあるだろ。
(…なんだが、対策出来れば実用言語としてはある程度は十分で、放置されて今があるわけだが)

>>658
仕様で決まってないことがあるから仕様準拠しなくていい、は草
流石にここまで行くと笑えてくるわ、そんなこと言いだしたらどんな言語でも仕様守らなくていいって結論しか導き出せない

それにサラッと話そらしてるけど未定義動作を書いてもいい理由にはなっていない
処理系に依存するのは別にいいけど、未定義動作は何が起きるかわからんから動かないコードとして扱う必要があるって話だからな

>>661
> そもそもこの仕様を変更したとして、誰にも何らデメリット無いのだから
それは君の思慮が浅いだけ

> 「このソースコードは動作します」なんて事はそもそも出来ない
仕様通りの環境で動作するコードは書ける
そこからはコンパイラの責任と割り切らないと >>638 みたいな矛盾が起こる

そして、各環境で使う時に動くかどうか検証するのはCに限らず当然
そこをCだけのことだと思っているようだが、実行環境依存の要素はどの言語にもある
エアプには難しいかなあ

>>659
不安定ソートと安定ソートに優劣はないよ
使い道が違うだけ
だからそこを勝手に差し替える方がまずい仕様変更

> 仕様準拠は主に(長期的な)生産性向上の為（＝ソースコードの品質を上げる為)として、
> 生産性を上げる為には仕様内の差異を潰す(仕様を絞る)事をしないといけない。
> 逆に言うと、仕様準拠だが実装がバラけるような「ユルい」仕様では意味がない。

お前やっぱC書いたことないだろって感じのことばっかり言うよな

流石に明らかに変なところに突っ込まないのは逆に怪しいから突っ込むけども、
> 仕様準拠だが実装がバラけるような「ユルい」仕様では意味がない
申し訳ないが意味不明

仕様準拠なら実装が違っても問題ないのは前提なんだわ
それは「高級言語」というものの定義の話としてそうで、逆に、そうじゃなかったらアセンブリ直接書けって話にしかならんのね
ハードウェアを抽象化した以上、仕様で提供される機能の範囲で書くというのは君が散々Cより改良されてると言ってる諸言語でも同じ

>>661
> そもそもこの仕様を変更したとして、誰にも何らデメリット無いのだから、

新しい仕様に依存したコードが書かれる様なるとそれに対応しない処理系の使用は絶望的になるからデメリット大きい。
適当に同じ処理まとめるだとか処理の順番入れ替えるだとかの自由も奪うことになると最適化の自由度も今より下がる。

>>658
> 生産性を上げる為には仕様内の差異を潰す(仕様を絞る)事をしないといけない
これはそもそも間違ったことを書いている
正しくは
> 生産性を上げる為には仕様内の差異を潰す(挙動を絞る)事をしないといけない
となる

で、なんでそんなことを必要とするのかと言えば、仕様に準拠しない書き方をしているからでしかない
仕様で保証されていない挙動を勝手に前提としてコードを書き、その通りにならない環境が出てくるからそういう作業が始まる
最初から仕様に定められた通りに解釈していれば、この無駄な作業は発生していない

>>666
それなんだよな
もっとも、最初から未定義動作踏み抜くようなクソコードしか書かない奴に通じるかはわからんが

>>657
マクロはC言語の仕様に含まれてるし、処理系定義もC言語の仕様に明記されてるんだけどなあ？
君の言ってる仕様って何の話？ｗ

C言語は仕様を完全に理解し未定義動作を絶対に踏まないパーフェクト超人向けの言語として舵切ってるのでJavaScriptみたいな素人向け言語の方針になびいたりすることは今後もなかろう。

>>658
> コンパイラ作成側が1mmも譲らず、あらゆる自由度を最適化余地の既得権益としてるからだが、
未定義動作の意味を理解していないからこんな妄想が出てくる
どんな言語でも仕様の範囲外をどう処理するかはコンパイラやランタイムの自由で、そういうコードは「書いてはいけない」というのは共通している
書いてはいけないコードを書いた結果壊れるのは当たり前で、コンパイラが悪いというのは的外れな主張だ

>>670
> C言語は仕様を完全に理解し未定義動作を絶対に踏まないパーフェクト超人向けの言語
これはガチ
別に舵切ったわけじゃなくて最初（仕様が公開された時点）からそうなんだけどね
だから「できない奴は去れ」なんだよな

>>666
資産はコードであって、コンパイラではない。
勿論、改修の手間も比べ物にならない。

> それに対応しない処理系の使用は絶望的になる
これまでのコードは全て動作するから問題ない。
コンパイラは改修すればいいだけ。

> 最適化の自由度も今より下がる
同上、要するにコードよりもコンパイラを優先する愚かな思考。
ここに自由度残してもバイナリの品質が上がることはほぼ期待できない。
なら、コードの品質を上げるべく、仕様を絞ったほうがいい。

>>670
おかしな選民思想を持たず、タダで出来る安全装置は付けるべきだろう。

>>673
> 資産はコードであって、コンパイラではない。
コードが資産なのにコードを動かせないコンパイラが支配的になると困るって話だろ
お前ホント日本語読めないよな
> コンパイラは改修すればいいだけ。
コンパイラも資産であるコードの一部であって、全部改修とか現実見てない奴しか言えないバカげた妄言の最たるもの

あと、まだ >>667 と >>671 で否定した
> コードの品質を上げるべく、仕様を絞ったほうがいい
とかいうバカげた主張を何の反省もなく繰り返してるんだな
バカの一つ覚えとはこのこと

> おかしな選民思想を持たず、タダで出来る安全装置は付けるべきだろう。
おかしな選民思想ではなく、ただの事実だよｗ
C言語は正しく書ける奴が正しく書くことを前提に仕様が決まっている
安全装置が欲しければRust書いてろって話

だから親切に最初からf93c-K2DKみたいな奴向けにRustはあるんだって言ってやってるのに、頭使えないからかバカにして見下してるせいで認められない

C言語は自分で仕様チェックしてその通り書ける奴のための言語
それができないならRustコンパイラに丁寧に教えてもらいなさいｗ

>>659
ソードってPIPSのSORD？

あそこは東芝が捕食した

最近はCで書いてAIにRUSTに書き直してもらってる

>>679
なんでそんな無駄な事する？
最初からRustで書かせればいいのに

>>659
> (ただまあ、個人的にはRustではないな、と見てる。あれはゴミだ)

ゴミとまでは思わないけど
宣伝文句に対して力不足だと思う
俺も出始めのころから2017年？くらいまでは熱心に追いかけてたけど
なんかもう特にコメントするところもない言語って感じ
Scalaなんかも出始めのころ画期的に見えたけどこれももう何も言うことはない

>>679
言語を変えるならjavaスクリプトからラストとかなら分かるけど、その例だとコード実行速度あんまり上がらなさそう

>>681
別に宣伝文句に対しては十分だろ
Cと同等の速度もメモリ安全も実現している
「驚きと楽しさで満ち溢れた古くならない言語！」なんて誰も言ってない

そもそも実用的なプログラミング言語に「驚きと楽しさで満ち溢れ」てもらっては困る

> ただまあ、個人的にはRustではないな、と見てる。あれはゴミだ (>>659)
> おかしな選民思想を持たず、タダで出来る安全装置は付けるべきだろう (>>673)
こんなこと言ってる奴はシステムプログラミング言語に手出しちゃダメ

安全にするためのルールにも文句を言う、でも安全じゃないのは欠陥だと喚く、要するに自分の忍耐も努力も足りないことを他人のせいにしているだけ

>>682
安全性を向上させたいのでは？
もっとも、最初からRustで書いた方がいいとは思うけど

やっぱAnnex Kってゴミだわ

_s 関数使えたもんじゃないよな

あれは失敗規格だから

エラー出たら勝手に落ちたり防ぎたかったら変なん渡さなきゃいけなかったりめんどくさすぎる

やっぱりMinGW使った方がいいな

あ、下げ忘れた

GNU/LinuxでGCCがいいよ

仮想ソフト使ってインストールしている

>>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 だとそうなってる。

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