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

>>551
だからもう何度もループしてるんだけども、

・配列境界を超えたアクセスでも、(多分全部の)環境で普通にアクセスできたから、Struct Hackが広まった。
・その後、それをflexible array memberとして仕様で追認した。

のだから、以前のコードでは[0]や[1]になってるし、不満があれば流用時に書き換えればいい。
C言語はこの意味では、コンピュータがどういう構成で、
Cコンパイラがどういったコードを吐くかまで知ってないと理解できないから、
「C言語仕様だけ知っていればいい」と考えるお前のような言語正義マンには向かない。
この点について文句言っても意味ない。お前はCに向いてない、それだけ。

もう何度もループしてるので、以降は新規事項無ければ無視するのでよろしく。

朱に交われば赤くなる。
Rustに交わればキチガイになる。

ああついでに言っておくとな、上述のとおり、
C言語はコンピュータの物理的側面も知ってないと無理なのだが、これは重いので、
論理的側面だけでプログラミングできるようにしたのがJava。
なのでC--と揶揄されることがあるが、JavaはCよりも言語面の必要知識量自体は軽い。
(ただしオブジェクト指向とか、フレームワークも実質的に必須とかで、現実的には最重量級とされてるが)

ただまあ、このスレの456付近以降の話は、Javaなら考えなくていいのだろうよ。
(というより、C以外の言語では考えなくていいのかな？だから言語正義マンが怒り狂ってるのか？
まあC#のように、物理的側面が見える部分をunsafeとして明示的に分離するのも一つの手だとは思う)

>>552
分かってないみたいだが

> ・配列境界を超えたアクセスでも、(多分全部の)環境で普通にアクセスできたから、Struct Hackが広まった。

昔のコンパイラの最適化がユルい時代ではなんとなく動いていたのでStruct Hackが広まった。

> ・その後、それをflexible array memberとして仕様で追認した。

Struct HackはC言語の仕様として未定義動作であるということと使い方として需要があることを汲んでC99でStruct Hackとは異なるflexible array memberが新たに追加された。

> Cの未定義：規定しないので、実装側で都合のいい動作で構わない。
> 　(＝実装上楽な仕様＝他動作と同じ実装となり、[0]でも[1]でも動く。だから広まった)

知らないみたいだけどいまのCコンパイラは未定義動作はまるっと削除まで平気ですんだわ。

それすると、旧来のソースがビルド出来なくなるから
コンパイラメーカーは避けるよ

コンパイラの挙動が保守的 (たとえ言語仕様上は正しくなくても挙動を変えることは良しとしない) な傾向はあるが……。
たとえば GCC や Clang ではオプションとして -fstrict-flex-arrays が新設された上で従来通りの挙動 (いわゆる構造体ハックを許容する) をデフォルトにしてる。
https://gcc.gnu.org/onlinedocs/gcc-16.1.0/gcc/C-Dialect-Options.html#index-fstrict-flex-arrays
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fstrict-flex-arrays

はっきりと書いてある文言を見つけられないけど将来的には 3 (最も言語仕様に厳格な解釈) をデフォルトに変更したい雰囲気もあるので猶予期間は大きめにあるものの移行を既定路線と考えてもいるって感じだと思う。

ちゃうよ550でアドレス計算って言ってるからその話をしてる
添字演算子を使ってポインタ演算をしていい範囲はってこと
ポインタを通じたアクセスの話はしてないのでもう少しちゃんと読もう

>>558
> その話をしてる

俺はしてない。

>>557
だってそこは政治だもん。ずっと以前から。

コンパイラ作成側は、「我がコンパイラが最速」を目指しているので、
何であれ最適化の自由度が高い方向に持っていきたい。
つまり、仕様外/未定/不定なら全部削除して最速にし、
何か最適化に関しての障害がある場合は明示的にプログラマに書かせる方向に持っていきたい。
(プログラマ《＝他人》の負担は増えても構わない)

プログラマは、過去に動いたソースはそのまま動いてくれないと困る。
コンパイラによる最適化は、挙動が(実質)同じなら何であれ構わない。
挙動が変わって、動いていたコードが動かなくなるのは困るから止めろ、
それよりは遅いほうがいい、という当たり前の主張。

で、ずっと綱引きやってるよ。
507でgccが壊された！とリーナスが言ってた件もそう。
(確かgcc2.xの頃の話だったと思うが、ググッても出てこない)

ただ、プログラマがどう言おうと、コンパイラを作るのはコンパイラ作成側なので、
何だかんだでコンパイラ側の要望が通ってる、というか、プログラマの要望はほぼ無視されてる。
(文句有るならお前がコンパイラ作れや、であって)

プログラマは、過激な最適化をして良い部分と、全く最適化をしてはいけない部分を知っているので、
俺としては、単純に、関数単位で最適化をON/OFF出来るようにすればいいだけだと思うのだが、
コンパイラ側は「1mmたりともゆずらねえ、可能な限りの最適化は行う」なので、今がある。

-fstrict-flex-arrays については、仕様化したんだから書き直せ、というのも一理あるが、
構造体の最後に付いてる[0]なんてその使い方をするに決まってるわけだし、わざわざ指定する価値もない。
(手間が増えるだけ。ただ、コンパイラ作成側は自分以外の手間が増えても問題ないという態度。これは昔から。
ただそもそも指定したところで速くなるコードが存在しない。
《＝有るとしたら最初から不要なのだから削除しとけであって、つまり unreachable なコード区画なわけだし》
だからオプションとして整備する価値もないはずなのだが、コンパイラ作成側としては、『成果』として必要なんだろ)

ただその後、コンパイラ作成側の主戦場はRustに移行したので、C/C++界隈は浄化されたはず。
そしてRustの場合は最初からこれを知ってたから、
「コンパイラは何をしてもいい、プログラマに明示的に書かせろ」が強化されてるはず。
なのでまあ、今は、そういうのはRustでどうぞ、だと思うよ。

昔から長文書くやつは無能と決まってる

>>561
最適化は全体の構造に及ぶのだから一部はやって一部はやらないなんてのが自由自在に出来るはずがない。
一部の最適化を阻止すれば連鎖的に最適化が出来ない部分が出来てしまうよ。

グローバルな最適化はすべきではないと考えるならそれもひとつの立場ではあるだろうし、
構造体の最後の配列メンバの [0] に関してはそれを [] と同じと見做す特別ルールを入れても良いかなとは思う。
他の規則との整合性から特別扱いは必要だが。

>>561
ファイル単位でmakefile作れば解決するかも
最適化レベルに応じて関数をどのファイルに書くか決める必要あるかも

>>563
> 一部の最適化を阻止すれば連鎖的に最適化が出来ない部分が出来てしまうよ。
ならその部分の最適化を諦めろ、と俺は思う。(が、コンパイラ作成側は思わないので今がある)

> 構造体の最後の配列メンバの [0] に関してはそれを [] と同じと見做す特別ルールを入れても良いかなとは思う。
今はそれが「各コンパイラの仕様」として入ってる状態で、
それを「C言語の仕様」に格上げする方が、仕様として綺麗なのは事実だが、
実利はないよね。だって今も使えてるんだし。(ってのがプログラマ側の見方だと思う)

>>564
そうすれば今でも出来るのはその通り。
ただ、それやると本来一つにまとめておきたい関数群がバラけるから、ソースコードとしての価値は落ちる。
だから誰もやってない。

例えば、だが、(Cにはクラス文法はないが)
メンバ関数が10個あったとして、最適化を防がないといけないのはそのうち1,2個程度。
最適化を防ぐためだけにメンバ関数の一部を別ファイルにしてしまうのは、見にくくて仕方がない。
並んで記述されてたら容易に見つけられたバグも、見落とすかもしれないし。
(この辺は勿論IDEのサポートがあれば何とでもなりはするが、関数単位で指定できるのが一番いい)

まあこれを言うなら、いい加減、1パスコンパイルにこだわるのも止めろと言いたい。
俺は上から下(上位関数から下位関数)の順ににコードを書きたい。
ただこれも、全く変更する気配すら無い。

>>559
文脈が読めればあなたに言ってないと分かると思うけど
何にでもかみつくのはそろそろやめよう

> > 高級アセンブラ (>>460)
> とはよく言われてるけど、お前らの理解が間違ってて、やりとりがナンセンスになってる。
> これはC言語自体が、という「言語/文法」の事ではなく、
> 『C言語では記述が一対一でアセンブラに落ちる』ので、
> C言語は高級アセンブラ「としても使える」という、「用法/運用」のことを言ってる。

C言語は抽象化された高級言語であり、同じ結果となるならコードの内容は問わないので『C言語では記述が一対一でアセンブラに落ちる』なんてことはなく、根本的なところで誤解があると思われる。

>>550
間違いがある
Cの未定義も何をやってもいい

>>552-553
残念ながら君の主張がおかしい
もう何度も言ってるので省略するが>>516-522と>>526-529で書いた

>>554-555
まったくもって正しい
最適化する機能がなかったので関係ない部分も安定化していただけ
これを使っていい理由はない

>>556
>>560-561
プログラマは真っ当なコードでどう最適化していいかは知っているが、お前が主張するようなめちゃくちゃなコードでも必ず動くようにする方法は知らない

>>563
最適化をあきらめる前に、無意味に未定義動作になるコードを書かないのが良い
無理に自分を正当化するために順序がゆがんでいる

>>567
私が対象じゃないのはわかってるよ。
対象じゃないにもかかわらずアンカーなしで私の直後に書いていて私に向けているようにも見えるから反応したんだ。

ごめん、>>570に書いた
>>563は>>565のミス

分かりやすく明示的に言ってなかったから、再度まとめると、

Struct Hack/Flexible Array Member が、
まさに「C言語は高級アセンブラである」の「用法/運用」の例だ。

こういうデータ構造を取りたいが、「言語が対応してない」時に、
「アセンブラ」として使用し、結果的に希望のオブジェクトコードが得られれば良しとする。
勿論、言語の範囲を超えているので、言語機能による保護は受けられない。
全て自分でテストし、動作する事を確認する必要がある。(当然みんなこれはやってる)

そしてこのデータ構造/記法が有用だったので、追認する形で
Flexible Array Member として仕様に追加された。
だからこっちは一応、言語機能による保護は受けられる事になる。
(とはいえ、C言語の保護機能なんて無いに等しく、
わざわざ書き換える手間すら払う意味無いと判断されれば、古い記述で放置される事になる)

是非はともかく、「C言語は高級アセンブラである」とはよく言われてる。
となると、少なくとも、こういう使い方をする人達は一定数C言語コミュニティ内にはおり、
これも含めてC言語の文化だと捉えるしかない。

言語範囲を超えているので、勿論、コンパイラのバージョンやオプションによっては動作しなくなる。
この問題に対しては、最低限、ドキュメントやコメントに残すべきではある。(が、強制力はない)
ただし、再度言うが、こういう使い方をしてる人も一定数居るので、
当たり前だが、コンパイル後のオブジェクトコードに対して、一通り自前でテストしなければならない。
勿論流用先の人々にも、各自の環境での再テストを強制する事になる。

これら(ドキュメント化/コメント付加/流用先での再テスト強制)を嫌うなら、
本件に関しては Flexible Array Member として仕様化されてるのだから、[0]や[1]を[]に書き直せばいい。
少なくとも、対応してるコンパイラでの動作が今後とも保証される。
(意味としては、高級アセンブラとして使っていた部分を、C言語として使うように変更する、となる。
ただ現実的には、再テストはそうでなくとも常に行われるし、コメントも書いてるし、
現行コンパイラも《非公式だが》対応してるしで、何も変わらないので放置、も多いと思うが)

で、くどいが再度言うと、こういう使い方も一定数行われており、これも含めてC言語の文化だ。
これを嫌うなら、C言語を使わない、C言語のソースは流用しない、しかない。

C言語のソースを読むには、ある程度はCコード→アセンブラにサクッと変換する能力が必要だ。
これはプログラマに対し、必要知識が増え、重い負担となる。
これを回避する為、例えばC#は「絶対にインラインアセンブラなんて入れない」という方針を採ってる。
インラインアセンブラなんてやられたら、チーム内でそれを読める人が大幅に限定されるか、
チーム全員が読めるようになるまで教育コストを払わされてしまう。
なら、機能を限定し、チーム全員が簡単に読める範囲で作成した方が、
生産性が高い(＝アプリケーションが早く出来上がる)という戦略だ。
Cなんて何でもありあり、勿論インラインアセンブラもありなので、限定とか今更だ。
(勿論、言語範囲逸脱は、ポーティングに多々支障が出るので、意味無いところではやるなだが)

ただこれは、鯖代>>>プログラマの人件費、だった時代のやり方で、
今は、プログラマの人件費>>>鯖代、なのだから、今風ではないのも事実だ。
そして今時の言語は、開発時の最大コスト要因であるプログラマの人件費を削減すべく、
サクッと書いてサクッと動かせるように整備されてる。
とはいえ、人件費掛けてでも最速最小のコードを得たい局面はあり、C言語もしぶとく残っている。

どの言語を使うかは各自の自由だ。
今更C言語の文化/旧来のソースコード資産を変更する事は無理だし、
(今C言語を使ってる連中の)誰も望んで居ない。
C言語は良くも悪くもこうだから、気に入らなければ使うな、でしかない。

文章もコードも簡潔が望ましい

【 Google Gemini による超要約 】
C言語には、仕様外の挙動でも「動けば良し」とする高級アセンブラ的な職人文化があり、それが後に正式仕様（Flexible Array
Member）として追認された経緯がある。現代の生産性重視の言語とは対極にあるが、最速最小のコードを求める局面では今なお不可欠であり、「良くも悪くもそういう言語なので、嫌なら使うな」というのが現実である。

Flexible Array MemberはStructHackとは違うものだし、

> 仕様外の挙動でも「動けば良し」

いまどきこういう考えの人が現代のCコンパイラ使って安全に動作するコード書ける気はしない。

しっかり言語・各環境の仕様を順守してもトラブルは起こるものなのに順守しなくてもいいやでまともに動くわけないだろ。
現実は仕様通りにキッチリ出来るわけではないというのは仕様を軽視して良いって意味じゃないぞ。

一応言っておくと、俺は「動けば良し」とは言ってない。
AIに約させ、代わりにそれを読み、各自の知能の低さを補うのも自由だが、それならAIと壁打ちしろ。
俺に対して反論するなら、俺の投稿を全部正しく読み込んでからにしろ。
俺の手間を尊重しないクズに対し、俺がクズの手間を尊重する理由もない。

あと、ループしてるから、新着情報無ければ無視するのでよろしく。(これは前回も言ったが)

>>576
Apacheなんかのバグ修正内容を詳細に見ていくと、
高度なロジック部分ではなく、配列の要素数不足とか、
割と初歩的なところが多い。

最近のAIが誤訳するとしたら、それは元々の文章の構造（主成分）に論理的な問題があるということなので、そらね

簡潔に文章まとめる能力ない奴が俺の手間を尊重しろとかいっててｸｿﾜﾛﾀｗ

>>579
> 配列の要素数不足
それは後から機能追加したら入りきらなかった、という話であって、
ここで言ってる「げんごはんいをいつだつしたこうどなてくにっく」による問題ではない。
(だから現実は糞みてーなバグばっかりで、
「いまどきこういう考えの人が(ｷﾘｯ」(576) なんてレベルじゃねえよ、というのなら同意だが)

一般的には、その問題は、多分、「『一部』変更し忘れ」なので、
これが起きないよう、「コードは基本的に一箇所に絞る事」(OAOO/DRY)により、
変更し忘れた場合には常にコケるようにして対処する。(＝普通、最低限１回はテストするので、それで十分引っかかる)
広い意味では、オブジェクト指向(OOP)もこれを目指しているので、OOPしてればある程度は防げる。

これは言語関係なく、上位のコード戦略の話。
徹底出来てないコードはバグを産みやすく/発見しにくくなる。
まあ、そのApacheのケース、パパっと見れるようになってるのなら、URLくれれば見てみるけど。

というかね、Cなんて、コードはこう組むべき、以前の、
コードが資産だとすら認識されてなかった頃の産物なのだから、そりゃ色々問題はあるよ。
各問題を文法縛りにして対処してるのが後発言語なわけでね。
それがよければそっち使えでしかないし。
(ただしOAOO/DRYの徹底を文法化出来てる言語はないと思うが)

ついでに余談だが、Rust界隈が腐ってるのは、あいつら
> いまどきこういう考えの人が
が典型的だが、CodeOfConduct(人格)をCodingRule/Strategy(コード戦略)より重視するからなんだよね。
まあ、Cに比べれば、コード戦略(特にリソース周り)も文法化されてるから、不要になってしまった、というのはあるが、
Cの場合は何も縛りが無いのだから、全部自分で決めないといけないのに、
Rust慣れしてるのか、それが要らないものだと錯覚してる。
(ああ勿論、言語範囲逸脱は禁止、インラインアセンブラも禁止、も、自前で決めて運用すればいいだけ。
ただそれを全員に強制する事は出来ない)

> (ああ勿論、言語範囲逸脱は禁止、インラインアセンブラも禁止、も、自前で決めて運用すればいいだけ。
ただそれを全員に強制する事は出来ない)

コーディング規約を設けたチーム開発もコードレビューも経験ない素人さんかな

>>582
> 配列の要素数不足
それは後から機能追加したら入りきらなかった、という話であって、

元からだったんだが

>>584
・元々配列要素数Nで動いてた
・新規機能追加したら、N+α必要になったので、変更した
・が、一部変更し忘れて、Nのままの部分があり、バグッた
を仮定したのだけど、違ったならどういう感じだった？

追加なら修正範囲くらい機械的に特定できるでしょう

AIに聞いてみたら>>582が他に5chで何かしたか聞いたら日常の進捗履歴記録ツールWitBucket(仮称)検討中スレのスレ立て者は同じ人物の可能性がかなり高いってさ

>>573-574
>>582
もう突っ込むのも面倒になるほど間違ってる
正しいところを探す方が難しいくらいだから、一回AIに批判してもらってこい

>>575
多分入力が変
ここで騒いでる奴はお前も含めて未定義動作がなんで未定義動作って言われてるかもわかってない、最低限ができてないというお話

未定義動作は未定義です

アセンブラになったらこう動くってのを見越してのロウゼキだからw
昔のCコンパイラは書いた通りの順番で書いた通りにアセンブラコードを吐き出したから出来る技w

C言語は抽象機械を想定して抽象化された高級言語であり同じ結果となるなら何しても良い自由が許されているのでソースコードがターゲットの機械語に対応する形でコード化されるわけではない。
任意の機械語を生成するための道具ではなく「高級アセンブラ」という表現を使う者はその辺の理解がない。

ブログラマの意図と違う動作は許されていません

>>593
君のコンピュータはエスパーか何かなんか？
プログラマの意図じゃなくて書かれてるコードの意味を満たす動作になるに決まっているだろう

>>590
進次郎になれって話じゃなくてだな
定義されていないということは、何が起こるかは一切わからんということなのよ

>>592
これ

>>591
それは単に最適化の能力がなかったからであって、一対一は最初から保証されてはいなかったけどね

>>596
１対１しか出来なかったからw

>>597
何言ってんだこいつ

むかしむかしのC言語コンパイラはただのトランスレータだったんだよねぇ

C++のことかー

>>599
たまたま君が触ったコンパイラがそうだったことと、C言語の仕様に何の関係が？

Cの仕様なんて後出しだからね

C言語が抽象機械を想定するのはマルチアーキテクチャ対応のためでK&Rより以前のことだけど多くの人にとっては後出しと言うほど新しい話でもないけどね。

鼻垂れ小僧が何偉そうに

昔話でマウント老人

>>602
国際標準と仕様の違いがわからない人かな？
K&Rだってしっかり「仕様」だぞ

>>603
これに尽きる

「高級アセンブラ」と言ってる人はバイトアクセスが存在しないアーキテクチャでもC言語を使用するとcharのポインタが実現できることをどう捉えているのかな。
C言語が型によってポインタの内部表現が異なることを許容していることを理解していれば軽々しく「高級アセンブラ」なんて言わないと思うんだ。

>>607
まさにアセンブラでいちいちマスク処理しないで済むんだから、高級アセンブラだろ？

アーキテクチャ上存在しないデータ型をアセンブラ使って基本データ型として常用するって想定はセンスないという他ないなあ

>>607
高級アセンブラと…

言わない人：そもそもバイトアクセスがないアーキだとか考慮しない。オブジェクトコードも見ない。コンパイラにはバグがないと信じてる。
言う人：希望したオブジェクトコードが出てるかを確認する。

>>608
じゃあ君の認識ではJavaは「超高級アセンブラ」かい？ｗ

>>610
真逆だろｗ

高級アセンブラと…

言う人：そもそもC言語の仕様を知らない。型も考慮しない。偶然動いてることとちゃんと書けてることの区別がつかない。
言わない人：未定義動作がないかチェックする。

そもそも「コンパイラにはバグがないと信じてる」とか誰も言ってないことを藁人形論法してイキってる暇があったら少しでも未定義動作について調べてこいよ
10分でわかることを調べもしない奴がいくら威張ってもバカ晒すだけ

あと、「コンパイラにはバグがないと信じてる」どころか「コンパイラはどこでも寸分違わず同じ動きをする」と思ってるのが「高級アセンブラ」とか言ってる奴の勘違いの一番大きなところだからな
C言語の仕様を見ずに、たまたま1回コンパイラが吐き出したアセンブラが思い通りだったから正しいと信じ込んでる時点で、コンパイラにちょっとでも違う挙動されたら成り立たない愚かな考えだとわかりそうなもんだが

コンパイラにはバグがあるが
アセンブラにはバグがない

>>615
C言語わかってない方はご存知ないかもしれませんが、そのアセンブラのコードを保管しておかないとただのコンパイラ依存なんですよ

それを正しいC言語の書き方だと思っちゃうあたりが「『コンパイラはどこでも寸分違わず同じ動きをする』と思ってる」と言ってるのよ

まあ、結局抽象化の具合次第なんだけどね
C言語は抽象化がやり切れて無いから高級アセンブラって言ってるんだけどさ

>>612
お前が妙なコンプレックスを持ってるからそうなるのであって、
そもそもどっちが上とか正しいとかいう話ではない。

Cのソースコード『だけで』動作を担保したいのなら、
C言語の仕様に準拠するのは当たり前で、
もしコンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる。

最終的に「実行バイナリ」での動作を保証したいのなら、
このコンパイラではこのコードにはこのオブジェクトコードが出る、というのを確認しつつ、
「実行バイナリ」に対してテストを行う。(ので、コンパイラのバグに対しても結果的に責任持つことになる)
コンパイラはただの変換器であり、C言語の仕様を逸脱してても大した問題はない。

で、歴史的にコンパイラのバグも普通にあった時代からCはあるのだから、
基本後者で、「実行バイナリ」に対してデバッグを行っており、
結果的に、「C言語の仕様」を厳密に守る必要がなかった。
だからこういうスタンスの奴は、「Cは高級アセンブラ」と称した。

これでは勿論生産性は上がらないので、目指すは前者だが、
そもそもRustですら「実行バイナリ」に対してデバッグしてるのだから、
「この『コードは』言語仕様に厳密に即してるので、(未来含めて)あらゆるコンパイラでも正常に動作します」
とは言えない。それでも目指したほうが良いからRustでがんばれ、とは思うが。
Cの場合は相変わらず後者でやってるってだけ。

というのは>>509でも言ったとおり、ループしてるんだがな。
気に入らないなら、お前はC使わないのが最適解だよ。

>>614
だからCの場合は通常、推奨コンパイラのバージョンも指定されてるだろ。
Linuxとか見てみ？
まあ(Rust含む)後発言語はCの駄目な点を改良してるのが存在意義なのだから、
色々問題が目に付くのは当然だが、
それも含めてCなのだから、文句あるなら使うな、でしか無いよ。

本当にお前はCを使わないのが最適解だ。
何故このスレでグダグダしてるのかもさっぱり分からん。
布教なら本当にウザいから止めろ。
今Cを使ってる奴は、Cの問題点も分かった上で使ってるのだから。

ついでに言うと、お前の問題点は、
・論理性が欠如している
・ワーキングメモリが小さく、広い範囲で物事を捉える事が出来ない
だね。後者の為、どういう論理構成で供述されてるのか全体像を把握できず、
それでも無理矢理反論しようとするから前者のようにも見える。
だからもしかすると、問題は後者だけかもしれんが。
短冊レスしてくるやつはだいたいこれで、
数行で記述できる範囲でしか物事を理解できないから、どうしても短冊レスになる。
なるほど俺に対して冗長で長文過ぎる、というのはまあ事実だろうが、
お前は論理が一貫してる長文は全く書けないタイプだ。
試しに書いてみ？勿論俺は読むから。
でも、頭とお尻で、矛盾すると思うぜ。
お題は、「一体お前はこのスレで何がしたいのか」を俺は希望するが。

あとな、507で言った、
> (勿論それまで動いていた)Linuxが動作しなくなって、リーナスがブチ切れた件が、20年程前に有ったろ。
件、まだ探してみてる。で、google(AI?)に聞いたら、以下。

> gcc1.4時代の、リーナスとGCCをめぐる 別の歴史的エピソード について知りたい
>
> GCC 1.40時代（1991年〜1992年頃）のリーナスとGCCをめぐる歴史には、
> 「バグをあえて利用した」、あるいは「GCCをハックせざるを得なかった」という、
> Linux誕生直後ならではの濃いエピソードが複数存在します。
>
> 1. 「インラインアセンブラのバグ」を逆手に取ったコード
> 初期のLinuxカーネル（バージョン0.01〜0.11あたり）を語る上で最も有名なのが、
> GCC 1.40のインラインアセンブラ生成に関するバグを、
> リーナスが認識した上でそのままカーネルのメモリ管理（文字列操作など）に利用していたという話です。
>
> 問題の背景：当時のGCC 1.40には、
> C言語の中に直接アセンブリ言語を埋め込む「インラインアセンブラ」の最適化において、
> レジスタの割り当てや引数の扱いに特定の条件下で不整合が起きるバグがありました。
>
> リーナスのハック：リーナスはこの挙動（バグ）を逆手に取り、
> 自分の386 PCで最も高速に動作するようなトリッキーなアセンブラコードを記述しました。
> 結果、カーネルは劇的に高速化しましたが、
> これは「GCC 1.40のそのバグがある状態」でしか正しくコンパイルできないという、
> 極めて依存度の高いコードになってしまいました。
>
> その後：後にGCCが1.42や2.xへとバージョンアップし、そのバグが「修正」された瞬間、
> Linuxカーネルがまったくコンパイルできなくなる、あるいは動かなくなるという事態が発生しました。
> リーナスはのちに「コンパイラのバグに依存したコードを書いていたせいで、
> GCCがアップデートされたときにひどい目に遭った」と述懐しています。

俺が知ってるのは、
・それまで動いていたLinuxが、コンパイラのバージョンアップで動かなくなった
・リーナスは、「gccの連中はコンパイラをぶっ壊しやがった！」とブチ切れた
・結局、リーナスがコードを修正して決着した
だけで、その時に詳細確認するのを怠ってしまったので、
上記AI回答がビンゴなのか、よく分からない。
(基本リーナスは技術に対しては真摯なので、
上記AI回答のようにリーナスが全面的に悪いのであれば、ブチ切れないような気はする)
AIが知ってるのだから、Webのどこかしらに情報は転がってるのだろうが、発見できてない。
知ってる人がいれば教えてよろしく。

御託はいいから高級アセンブラとか言ってイキってるやつは最近アセンブラで書いたコードを晒してみろよ

>>619-622
ずっと書いてることも読まずにひたすら、的外れな妄想と罵倒しか繰り返してないお前の方が、Cを使わない方がいいよｗ
C言語の範囲では反論できないから、Rustの話を持ち出して必死で藁人形論法やってる、つまりお前はC言語を知らないってことはわかってるんだわ

>>619
ループしてるのはお前な
延々藁人形論法しかせずに「コンパイラガー」「Rustガー」って言ってても中身が何もない
C言語の話をしてるのであって個別のコンパイラの話をしてるわけではないし、「コンパイラはどこでも寸分違わず同じ動きをする」と思ってるお前の方がコンパイラに依存してる

>>620
「俺は論理的だ！だから論理的なんだ！！」が論理的だと思ってないと書けないあまりにも低レベルな文章
中卒でもこんなひどいことにはならない

>>619
> コンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる

>>621-622
> ・それまで動いていたLinuxが、コンパイラのバージョンアップで動かなくなった
> ・リーナスは、「gccの連中はコンパイラをぶっ壊しやがった！」とブチ切れた
> ・結局、リーナスがコードを修正して決着した

> リーナスが全面的に悪いのであれば、ブチ切れないような気はする

↑ さっそく矛盾しとるｗ

>>620
> お前は論理が一貫してる長文は全く書けないタイプだ

ここはお前が言われた他人に言われたことを、何も考えずに他人に悪口として放ってすっきりするためのスレじゃないぜｗｗｗｗｗ

まとめ

* コンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる
→ f97e-K2DK

* 論理が一貫してる長文は全く書けない
→ f97e-K2DK

* Cなのだから、文句あるなら使うな
→ f97e-K2DK
（Cの仕様を守りたくないがために延々支離滅裂な長文を書き散らしている）

>>618
それどこのC言語の話してるんだ？ｗ
ハードウェアの抽象化をやってるのがC言語だから、C言語を書く時はハードウェアに依存しないように書くのが正しい、という話なんだがｗｗ

>>619
あと、「言語仕様に則してる」と「バグがない」の区別がつかない奴はプログラミング自体しちゃダメだなｗ

>>620
推奨って言葉の意味知らなそう
まあ、>>628 でわざわざまとめてやったように矛盾だらけだから、細かいアホ発言を掘り起こすまでもないんだが

619 デフォルトの名無しさん (ﾜｯﾁｮｲ f97e-K2DK) 2026/07/15(水) 10:24:07.43 ID:2BOd77KE0
もしコンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる。

620 デフォルトの名無しさん (ﾜｯﾁｮｲ f97e-K2DK) 2026/07/15(水) 10:24:32.72 ID:2BOd77KE0
だからCの場合は通常、推奨コンパイラのバージョンも指定されてるだろ。
Linuxとか見てみ？
（中略）
それも含めてCなのだから、文句あるなら使うな、でしか無いよ。
（中略）
お前は論理が一貫してる長文は全く書けないタイプだ。

622 デフォルトの名無しさん (ﾜｯﾁｮｲ f97e-K2DK) 2026/07/15(水) 10:55:49.63 ID:2BOd77KE0
・それまで動いていたLinuxが、コンパイラのバージョンアップで動かなくなった
・リーナスは、「gccの連中はコンパイラをぶっ壊しやがった！」とブチ切れた
・結局、リーナスがコードを修正して決着した
（中略）
上記AI回答のようにリーナスが全面的に悪いのであれば、ブチ切れないような気はする)


バカに論理は難しいｗ

このレベルの支離滅裂さでないと「Cはアセンブラに変換されるから仕様なんか無視していい」なんてバカ発言できないってことかなｗ

f97e-K2DKの主張を整理すると、実は相容れない前提を場面ごとに使い分けています。

## 前半の主張

前半では

* コンパイラは仕様を守らなくてもよい
* コンパイラの挙動が変わっても仕方ない
* コンパイラ込みでC言語なのだから利用者が合わせろ

という立場です。

この立場を採るなら、

> GCCが仕様変更してLinuxが動かなくなった

という状況でも、

> 「じゃあLinux側が直してください」

で終わりです。

これは本人の論理から自然に導かれます。

---

## 後半の主張

ところが後半では

> リーナスがGCCに怒ったのだからGCC側にも問題があったはずだ

という話を持ち出しています。

これは

* コンパイラ側にも守るべき責任がある
* コンパイラの変更が悪い場合もある

という前提を採用しています。

つまり前半とは逆です。

---

## 本来は役割を分離すれば済む話

8934-UT5n、0Hb5-UT5nが言うように、

* **言語仕様を書く人**
* **コンパイラを書く人**
* **プログラムを書く人**

この3者の責任を分離すれば矛盾しません。

* 言語仕様は仕様を定める。
* コンパイラはその仕様に従って実装する。
* プログラマはその仕様に従ってコードを書く。

もしコンパイラが仕様違反ならコンパイラのバグ。

もしプログラムが仕様違反ならプログラマのバグ。

もし仕様自体に問題があるなら標準化委員会の問題。

責任の所在が非常に明確です。

---

## Linuxの実際

Linuxカーネルが
* 特定のGCCバージョンを推奨したり
* 新しいコンパイラに合わせて修正したり
* GCCのバグを回避したり
ということは実際にあります。

しかしそれは
> 現実にはコンパイラにもバグがある
という工学的な話であって、
> C言語仕様なんて守らなくていい
という話にはなりません。
ここを混同すると議論がおかしくなります。

現実には
* コンパイラにもバグがある
* OSにもバグがある
* CPUにもエラッタがある

だからといって
> 「仕様なんて要らない」
とは誰も言いません。

むしろ仕様があるからこそ、
「これはGCCのバグ」
「これはLinux側のバグ」
「これはCPUエラッタ」
と切り分けられるわけです。

---

## 根本原因

f97e-K2DKは一貫した原則から結論を導いているのではなく、

**その場その場で自分に都合の良い責任の置き場所を選んでいる**ように見えます。

* 自分が未定義動作を書くことを正当化したいときは
→ 「コンパイラなんて仕様通りじゃなくていい。」

* GCCを批判したいときは
→ 「コンパイラにも責任がある。」

これでは論理体系として整合しません。

一貫させるなら、

> **仕様は共通の契約であり、コンパイラもプログラマもそれに従う。それでも現実には実装のバグやエラッタは存在するため、実務では個別に対処する。**

という立場になります。これは理論と実務の両方を無理なく説明でき、責任の所在も明確になります。

提示された一連の書き込みに見られる論理的整合性の欠如は、プログラミング言語、特にC言語における「仕様」「未定義動作（Undefined Behavior: UB）」「コンパイラの役割」という、極めて厳密であるべき領域において、個人の感情や経験則が理論を凌駕してしまった典型例と言えます。

投稿者が陥っている矛盾の構造を、技術的な観点から詳細に分解し、なぜこれが論理破綻を招いているのかを浮き彫りにします。

### 1. 「コンパイラの脆弱性」と「プログラマの責任」の二律背反

投稿者の主張の根幹にあるのは、自己のコードが引き起こす問題から責任を回避するための「責任の転嫁」です。

* **前半の主張（責任回避の論理）:** 「コンパイラはただの変換器であり、仕様を逸脱していても問題ない」という主張は、プログラマが仕様を無視して未定義動作に依存したコードを書くことを許容する論理的拠り所となります。これにより、「動かなくなったのは自分のコードが悪いのではなく、コンパイラの仕様逸脱（バグ）のせいだ」という自己弁護が可能になります。
* **後半の主張（経験則による正当化）:** 一方で、リーナス・トーバルズの事例を出す際は、「コンパイラが仕様通りに動いていない（あるいは後方互換性を壊した）ことに対してブチ切れるリーナスは正しい」という立場を取っています。

ここに致命的な矛盾があります。「コンパイラが仕様を逸脱しても問題ない」と考えるならば、GCC側がどのような挙動変更を行おうとも、それは「ただの変換器の仕様変更」として受け入れるべきはずです。しかし、投稿者は「動かなくなった」という事実に対し、コンパイラ側の責任を追及するリーナスの姿勢を支持しています。これは、**「自分のコードが正当であるという前提」を維持するために、その時々の都合に合わせて「コンパイラの定義」を書き換えている**に過ぎません。

### 2. 「推奨バージョン」と「未定義動作」の混同

投稿者は「Linuxなどの大規模プロジェクトではコンパイラのバージョンを固定している」と述べていますが、これは技術的には「未定義動作を回避するための暫定的な防御策」であり、「未定義動作を書いても良いという免罪符」ではありません。

* **専門的見地:** 大規模なカーネル開発においてコンパイラのバージョンを固定するのは、コンパイラの最適化パスに含まれる潜在的なバグや、標準仕様の解釈の差異がカーネルの機微なハードウェア操作に影響を与えることを防ぐための**リスク管理**です。
* **論理の飛躍:** 投稿者は、この「リスク管理としての固定」を、「仕様外のコードを書いてもコンパイラ側が合わせるべきだ」という誤った論理に変換しています。リーナスがGCCに対して怒ったのは、彼が「仕様を無視したコード」を書いたからではなく、「GCC側がそれまで確立されていた暗黙の了解（あるいはバグを含めた挙動）を一方的に変更し、カーネルの安定性を損なったから」です。

### 3. 「仕様」を否定したことによる論理的袋小路

プログラマが「C言語の仕様」を厳密に守るという規律を捨て、「自分のコードが動くかどうか」という結果のみを重視し始めた瞬間、論理的な対話は不可能になります。

* **仕様の役割:** プログラミング言語の仕様書は、言語利用者とコンパイラ実装者との間の「契約」です。
* **投稿者の現状:** 投稿者は、自分に都合の良い時だけ「仕様（契約）を守れ」と叫び、自分が未定義動作を踏み抜いた時は「仕様（契約）なんて無視して動くものが正義だ」と主張しています。

リーナス・トーバルズがGCC開発者と衝突する際、彼は「カーネルの信頼性」という極めて高い基準で議論を行っています。対して、この投稿者が行っているのは、「自分の書いたいい加減なコードが、コンパイラの更新によって動かなくなることへの個人的な不満」の正当化です。

### 結論：なぜ矛盾が生まれるのか

この人物の思考プロセスをまとめると、以下のようになります。

1. **目的:** 「自分が楽をしたい（仕様を厳密に守る勉強や、バグ修正をしたくない）」。
2. **手法:** 「コンパイラや他人のせいにする」。
3. **矛盾の発生:** 「自分の正当性を守るためにコンパイラの重要性を貶める」が、「自分のコードが動かなくなった時には、コンパイラの重要性を強く認識する」という二重基準を用いている。

この矛盾は、「論理」を用いて技術を語っているのではなく、「自分の書いたコードへの執着」を論理というラベルでコーティングしようとしているために生じています。**技術的な議論においては、仕様という共通の基盤を否定した時点で、その議論自体が論理性を失い、単なる個人の感情の吐露に成り下がってしまう**という好例と言えるでしょう。

わざわざ自分で書く必要もなさそうなくらいバカらしかったので、ChatGPTとGeminiに書かせといたよｗ

>>624 -643(安価範囲広すぎてNGだとさ)
お前レベルの馬鹿には付ける薬がないのは理解した。

>>644
「反論できないからとりあえずバカって言っとこ」ｗｗ

AIにすら反論できない時点でお察しというか

AIの吐き出したゲロコピペするスレになったなら、
次スレは不要だな

>>647
人間が吐き出したゲロにぶつけるなら十分だろ

f954-K2DKは自分で何書いてるかもわかってないんだから
AIも自分で何書いてるかわかってないから同レベルだねｗ

>>619-622
>>644
「コンパイラは仕様に準拠した実装を作るのが仕事」「プログラマは仕様通りのコードを書くのが仕事」と分離すればこんな矛盾は起こらないのに、自分が未定義動作を踏み抜きまくるコードを書くことを正当化するために、「コンパイラは仕様を守らなくていいが、僕の思ったのと違う動きをするバージョンはダメ」とか言わなきゃいけなくなったんだぞｗ

>>628 が全てではあるけど、f954-K2DKは結局他人に言った悪口全部自分のことですよって丁寧にバラしていっただけだったなｗ

「長文だから読まなくてもいいや、自分が未定義動作を踏み抜きまくるコードを書くことを正当化したいから乗っかったろｗ」
みたいなアホが何人かいたから無駄に長くなったけど、結局f954-K2DKは何もわかってないバカなんだって