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

>>444
できることと効率がいいかどうかは別物

効率の良い方法でどうぞ

>>443
C#とかさ、オーバーフローしたらエクセプション出して落ちるけど
あれ、地味に要らない機能だよなって思う

>>443
標準になってないが普通コンパイラがintrinsic提供してる
高速な多倍長整数を自作できてようやくC言語中級レベル

>>448
それはお前がエンジョイ勢だから

>>449
足し算引き算はなんとか
かけ算も頑張ればできそうな
割り算は、ちょっとやっかいかも

かつてubasicというソフトがあって、
今もあるかは調べていないが、
多倍長演算が出来て、結構使える。
πを1000桁まで計算するサンプルが掲載されていた。

開発効率より実行速度命やろ

今でもCに固執する変態は実行速度命

世界を変革しているのは変態パワーだぞ

>>439
C言語の仕様は抽象マシンにおいてどう動くかという形でしか定められていない
コンパイラはそれを環境に合わせて自由に実装することが許されているので、コンパイラの仕様はC言語の仕様では定められていない

>>431
負の数を表現する時ではなく、表現できるようにする時やな
ここは重要

>>440
C言語において2の補数はC23で初めて取り込まれた仕様で、あくまで現代ではほぼ全てのハードウェアがそうだから前提にしましょう、という話でしかない
ハードウェアのためにそうなったのではなくて、前提にしても問題ないならそれを前提に機能が作れるよねと、それだけの話だから

>>439
C言語の規格仕様とコンパイラの仕様が別物なので、コンパイラの仕様がハードウェアの仕様といくら密接に関係していても、C言語の仕様がハードウェアと密接に関連していることにはならない

>>438 には「C言語の仕様」と明確に書いてあるのに >>439 は「コンパイラ」の話に一足飛びで (話がそれたとか言うレベルではなく) 置き換えてる意味不明ムーブなので意図的な荒らしだと思ったんだけどこのスレにいるような人でも区別をつけてないってことがあったりするもんなの？

高級アセンブラだと考えています

>>460
結構組み込みの人の本なんかにも書いてあるんだけどそれもちょっと違って、アセンブリ言語はハードウェアに密接に関係し、データをCPUの提供する型でしか扱えない
例えば文字列リテラルやオブジェクト、配列のような概念はアセンブリ言語には存在しない

そういうものが使えるアセンブラだと考えれば良いです

C言語でいう配列って、先頭アドレス情報くらいでしょ。要素数さえ情報として持っていない

考えるのは自由
どうでもいいから心のなかにしまっとけ

みんな言ってない？

>>462
そんなことを言い出したらどんな高級言語でも「そういうものが使えるアセンブラ」になる

>>463
典型的な誤解で、配列型は存在するし sizeof(arr) でサイズを取得できる
typedefで特定の型の要素を特定の数持った配列型に別名をつけることもできる
ただ、代入など特定の式で扱われる際にポインタにdecay（減衰）するというだけ
C言語では引数の処理を代入と同様に扱うことを定めているので、関数を跨ぐとdecayする

例えば整数型変数を用意して、それをバイト単位で切り刻んで加工出来る。
実際に行う際は、そのCPUがどのようにメモリー配置するのかの知識も必要になる。
よく切れるナイフや包丁は役に立ちます。怪我もしやすいですが。

>>467
C言語はコンパイラによって最適化されるので、コードからメモリ配置を把握することはできない
一見するとメモリに書き込むように見えても、実際はレジスタ上から動かないこともある

メモリーに書き込まないと、
他の処理とやり取りできませんよ

配列にサイズ情報があれば
領域破壊も避けられるんですけどね。
C言語は100個用意してから200個でも格納できます。
出来ないようにしてくれる方が
バグは減ると思いますよ。
あとから見つけるのは、結構大変です。

>>469
レジスタにあれば同じプログラムの中で扱うのに不都合はないんですよ
詳しくはまた調べてみてくださいね

>>470
配列にサイズ情報はありますよ
領域破壊が起こるかどうかとサイズ情報は関係なくて、サイズ情報があってもガードする機構がなければ領域破壊は起こります
実際に sizeof(arr) を試してみるとわかりやすいですよ

コンパイル時にサイズがわかっているって話（sizeofによるサイズ）と
実行時に配列のサイズを知ることが出来るって話がごっちゃになってると思う

>>472
君こそ実行時とコードがごっちゃになってる
実行時は全部機械語だってことはわかっておかなくちゃね

機械語で型のサイズがわかる型っていったい何なんでしょうか（笑）

キチガイがいますね

初心者か苦手なポインターって、メモリー内の位置を指し示して、
そこを自由に書き換えます。
他の言語では難しい、結構危ないことやってます。

a[16]って宣言した配列に、
a[20]で代入してもエラーにならない
これも他の言語にはない機能です。

アセンブラ使いが楽する為にある言語だからねぇ

関数の引数のときに問題が起こるけど
全ての関数の引数に要素数を追加すれば解決するし
昔と違って最近は標準ライブラリも改善されてる

>>477
そもそもC言語の添字表記はポインタ演算ですよ
decay発生後です

それはチームなりサイトで決めれはそうでしょうが、
どこでも通用する共通なものではないよ。
そんな面倒なことするくらいなら、❌❌使えって返されるだけだし

>>481
いいえ、言語仕様ではっきり定められています
それもK&Rの時点からそうです

>>478
それは割と無理がある
その論法では同じことがPythonにもJavaScriptにも言えてしまうし

だから >>477 のこれは上は配列型、下はポインタでやってることが違う

語り尽くされた話を意気揚々と語り始める老人たち

>>483
プログラミングの歴史でも読んでから出直してね

>>486
オマエガナーｗ

全てのプログラミング言語は最終的に機械語に直されるんだよ
だからC言語が「アセンブラ使いが楽する為にある言語」なら全部そうなる
プログラミング言語で最も重要な、抽象化について理解してないんだから

>>485
その基礎中の基礎がわかってない奴がいるからな

>>487
頭沸いてんねw

>>489
罵倒はできても基礎の基礎が理解できないってことが露呈するばかりｗ

C言語はハードウェアの詳細を抽象化した言語だから、アセンブリ言語を見て「こうなるんだ」と思ってるのは間違いなのよ
そのアセンブリ言語はあくまで「特定のアーキテクチャで」「特定のコンパイラで」「特定のバージョンで」「最適化の度合いによって」選択された実装に過ぎない
C言語が保証するのは、各構文や型、修飾子などが提供すると定めている機能までであって、それは他の高級言語とも何ら変わることはない
それ以上の実装詳細は全て実装側に任されている

だからC言語はアセンブリを楽に書くためのものではなくて、あくまで抽象化されて提供された機能から必要な挙動を生み出すものでしかない
それ以上のことをやりたければ自分でアセンブリを書きなさいという話になる

K&Rは昔のC言語の雰囲気が分かることくらいしか価値がない

C言語インタプリタもあるしな

>>493
まあ、設計者自身が書いてるから流石に設計思想はわかりやすいよ
ただ、仕様は古すぎるし今のC言語では認められていない、あるいは非推奨な書き方も多いから最初に読む本じゃないね

>>494
存在を忘れてたけどそうね、あれもC言語の仕様には反しない
昔使ったことあるわ懐かしい

> a[16]って宣言した配列に、
> a[20]で代入してもエラーにならない
> これも他の言語にはない機能です。

未定義動作と定められてるものをC言語の機能って言っちゃう馬鹿さ加減はどうなんだ?

構造体メンバーの最後に配列をa[0]で宣言しておいて、使うときに適当なサイズに拡張する、なんて使い方はよくやる
gccなら使えたはず

前に別人が書いてるように
配列の要素を越えようとポインター操作なんで問題ないそうだ笑

> 構造体メンバーの最後に配列をa[0]で宣言しておいて、使うときに適当なサイズに拡張する、なんて使い方はよくやる

処理系の拡張と言語仕様の区別がつかない人かな。

突っ込む所が全然間違えている
要素が0の配列に何故目か向かないのか？

>>497
そういう用途のために C99 以降はフレキシブル配列メンバ (flexible array member) が導入された。
言語仕様内で出来る方法があるときにあえてそうでない方法をとるべきではないだろう。

Cに関しては言語仕様は後付けだから
おまえらが今使ってるC言語になるまで
どんだけ掛かったのかってな
今では危険なアクロバチックな使い方も
昔は最終的にアセンブラで辻褄合ってれば
無問題だったんだよ

> 今では危険なアクロバチックな使い方も
> 昔は最終的にアセンブラで辻褄合ってれば
> 無問題だったんだよ

コードが再利用される想定がないから無問題なんて軽々しく言えちゃうわけよ

んー、あんま意味無いやりとり続いてると思うけど、

>>502は正しいよ。実際、flexible array memberについては完全にその通りだし。
> C99以前のコンパイラの中には、ゼロ長配列 Element items[0]; を可変長配列メンバーの代わりとして許容するものがありました。これは標準にはありませんが、歴史的に使われてきたトリックです。しかし、可変長配列メンバーが標準化された今、この方法は非推奨です。
> https://iifx.dev/ja/articles/457531504/%E5%8B%95%E7%9A%84%E9%85%8D%E5%88%97%E3%82%92%E8%87%AA%E5%9C%A8%E3%81%AB%E6%93%8D%E3%82%8B-c%E8%A8%80%E8%AA%9E%E3%81%AE%E5%8F%AF%E5%A4%89%E9%95%B7%E9%85%8D%E5%88%97%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%A8offsetof%E6%B4%BB%E7%94%A8%E8%A1%93
> properties_table[]ではなくproperties_table[1]と書いてるのは、おそらくC99より前のバージョンのC言語ではサイズ0の配列の宣言ができなかったらしいので、その辺の名残りでしょう。
> https://mem-archive.com/2018/08/10/post-529/

> 高級アセンブラ (>>460)
とはよく言われてるけど、お前らの理解が間違ってて、やりとりがナンセンスになってる。
これはC言語自体が、という「言語/文法」の事ではなく、
『C言語では記述が一対一でアセンブラに落ちる』ので、
C言語は高級アセンブラ「としても使える」という、「用法/運用」のことを言ってる。
例えば c = a + b で最適化前なら、
LD/LD/ADD/STとか、勿論CPUに依るが、お前らがそのまんま書くだろうアセンブラが出力される。
他の言語では、これはありえない。
(Cでは、書いてない事は何も実行されない)

逆に言うと、どういうアセンブラに落ちるのか、意識しながら書く事も必要で、
(アセンブラではどうとでもなるが) myStruct->myFlexbleArrayMember の表記を使いたかった時に、
みんなそれなりにやってたのを『後付で』標準化しました、って事でしょ。

>>503
お前はC言語を使わないほうがいい。
C言語に於いては、妥当な使い方で、バグがなければ、それでヨシとされてる。 flexible array member もこれ。
デタラメな使い方でもバグがない事を検出してくれ、は、他言語の範疇。
(ていうかお前多分釣りだろ？迷惑だから止めてくれ)

検証 (処理系の挙動の調査) に手間をかけるくらいなら言語仕様になるべく沿う方が現代的には楽だが、昔の処理系ではどうコンパイルされるかかなり意識可能であったことも、今でも必要であれば言語仕様外の挙動に依存することはそれなりにあるのも正しいと思う。低レイヤの細部を全く制御しないなら C を使う意味がない。
ただ、十分に検証しているか疑わしいと思うことも多いし、言語仕様に逆らうなら言語仕様に逆らっていることに自覚的であるべき (その前提として言語仕様はよく理解しておくべき) だし、逆らったことはドキュメントやコメントとして書いておいて欲しいと思う。

>>505
> 言語仕様に逆らうなら言語仕様に逆らっていることに自覚的であるべき
具体的には何の事を言ってる？
504で挙げた連中なら、「その時の一般的記法」「コメントに残す」はやってたようだし、
その批判の対象から(意図的に)除外されてるように見えるが？

> ただ、十分に検証しているか疑わしいと思うことも多いし
多分逆。
(今も再利用されるようなコードなら)その人が書いた環境では十分にテストもされ、バグもなかった。
ただそれを「Cコード」として他環境に持ってきたとき、
未定義/コンパイラ依存部分に当たってたら、動作するとは限らないので、
標準化して『どんな環境でも』動作するようにしました、というわけだろ。

これは、この「Cコード」は動作します、という受け取り方がマズいって事なのだと思うよ。
それは「コンパイラにはバグがない」という大前提であって、
実際はそうでもないので、製品としては「実行バイナリ」に対してのテスト/保証しか出来ない。
(コンパイラのバグに当たっても製品の責任になるし、
テストも「Cコード」ではなく、Cコードを特定環境でコンパイルした「実行バイナリ」に対して行われるので、
そもそも「Cコード」の正当性がテストされているわけではない)
ただこれでは勿論困るので、
「コンパイラにはバグがない」時に『正しい』「Cコード」ならどんな環境でも確実に動作するよう、
規格化/標準化が行われている。
だから言語として出来る事は『正しい』事を強制する事であり、
例えばC#では、未初期化の変数はSyntaxErrorとなる。
しかしCの時代にはCPUは非力だったし、「初期化もタダではない」ということで、
malloc/callocのどちらを使うかはプログラマに任せてある。
それが嫌なら、Cの思想と相容れないのだから、気に入った他言語を使えばいいだけ。

ちなみに「Cコード」がテスト出来てるかについては、コンパイラグループが最適化を好き勝手にやった結果、
(勿論それまで動いていた)Linuxが動作しなくなって、リーナスがブチ切れた件が、20年程前に有ったろ。
結局、論理的にも、「実行バイナリ」に対してのテストしか出来ないんだよ。
(勿論最適化無しならその時にも動いたのだから、一般的にはコンパイラのバグとされるが、
この件についてはリーナスが折れた《うろ覚え》)

> >>502は正しいよ。実際、flexible array memberについては完全にその通りだし。


Flexible Array Memberが規格化される前は要素数を空に書けなかったので

struct Packet {
int length;
char data[1];
};

要素数に1とか書いて今でいうFlexible Array Memberと同様の使い方をすることを Struct Hack とか呼んでたけど、現代のコンパイラは未定義動作を積極的に最適化に利用するようになったので要素数を1と定義した配列の[0]以外にアクセスするのは未定義動作となるため結果はどうなるか分からないいわゆる「鼻から悪魔」なので Struct Hack を使ってるコードは今どきの処理系では再利用性は低くなってしまっている。
gcc なんかでは救済措置として不具合を出さないためのコンパイルオプションが用意されてたりもするけど環境依存の話でしかないし C言語として正しいわけではない。

>>508
やはりお前はCを使うべきではない。それだけ。

> 今どきの処理系では再利用性は低くなってしまっている。
だから何？
> gcc なんかでは救済措置として不具合を出さないためのコンパイルオプションが用意されてたりもする
当たり前だろ。

書く側は、その時その環境で動作が正しい事しか保証出来ない。
これはコンパイル言語では全てそう。勿論Rustでも。(俺はお前がRust信者＝キチガイだと見ている)
だから、流用する側が、どういう環境で動作していたか、どの環境でテスト済みかを判断する必要がある。

これが嫌なら、JavaScriptと同様に、「コード自体」をテスト対象とし、
どんな環境(ブラウザ)でも動く事をテストするしかない。(そしてこれはJSerに取ってはかなり苦痛になってる)
これを保証する為、JavaScriptは、例えばindexOfですら、動作を糞みたいに細かく仕様として決めてる。
対して、それ以外の言語では、有ればそのインデックス、無ければ-1、で完全に間に合ってるのにだ。

同様に、「あらゆる環境で、(未来含めた)あらゆるコンパイラで、このコードは、動作する」事を保証出来ると思うのなら、
やってみればいい。がんばれ。

なお、
> 配列の[0]以外にアクセスするのは未定義動作となるため
余程おかしなコンパイラではない限り、実装は同じ(配列頭に個数分のアドレスを足すだけ)なので動く。
だからみんなそれで理解出来てた。

結局、Cは、論理イメージのみでプログラミングする奴には、向いてない。
(基本的に論理イメージだけで出来るのは、Java)

そして
> C言語として正しいわけではない。
だから本当に何？というか本末転倒だろ。
お前は何の為にコードを書いてる？
「再利用出来る糞コード」を目指すのはRustだぞ。
Cは、「俺が処理したいように書く」のであって、言語に足なくてもやる、だから flexible array member になった。
結果的にそれが素晴らしいから再利用されるのであって、あくまでそれは結果だ。目的ではない。
気に入らない部分が有るなら、流用する側が流用時に書き換えればいいだけ。

Struct Hack では未定義動作の問題があるが機能としての需要が認められて flexible array member が C99 に盛り込まれたことが理解できないんだなあ。
未定義動作を屁のように考えてる人は程度が低すぎるので業務でコード書かないでほしい。

>>511
多分お前は根本的に理解出来てないのだろうが、一応言っておくと、

・flexible array memberなり、Struct Hackであれ、そのコードで動作しないコンパイラは多分無い。
・Cプログラマが直感的に予想する通りに動くコードが得られる記法だった。
・一般的に最速最小メモリの実装になるので、それを使う人が多発した。
・結果、後付で「今までと同様に動くように」仕様化された。

のであってな、[0]であれ[1]であれ、元々動いてるコードが、仕様化されただけ。
PHPにそれが存在してるのだから、モロクソ業務で使われてるし、誰も気にしてないだろ。
多分Linux等でも普通に使われてると思うぞ。だってそれが最速最小メモリだし。

まあ、Cには正義マンは要らないってことだよ。

>>511
付け足し。
Cは多分、物理配列であることが仕様化されてる。
だから、[0]であれ[1]であれ、まあ動くに決まってる。
(これを未定義と呼ぶべきかは微妙な気はするが、まあ未定義ならそれでもいい)

Javaは論理配列なので、この辺は動かない、というか、動くことを保証されてない。(多分そもそもアクセスできない)
だからお前が論理配列のイメージで考えてるなら、そこが間違ってる。

たまたま動いてるコードを安全とみなすのは普通にバッドプラクティスだからそんなことで威張られても困る
それはたまたま動いてるのであって誰も保証していない
C言語の仕様は保証される範囲を定めることによって移植性を実現しているし、その範囲で書くように作られている

>>514
・たまたまではなく、そのコードで動かない環境は多分無い。
・それでも気に入らなければ、該当部分を書き直すか、そもそもCコード自体を流用しなければいい。
・今は他に沢山言語もある。

のに、何故お前はグダグダ言い続けてる？
そういう連中は、C使うのを止めるのが最適解だと思うが。

>>502
>>504
そんなことはなくて、K&Rでも「動く場合はこうしなくてもいい」などということは書いていない
特定の集団における単なる慣行を言語の話と主張するのは無理がある
「C言語では記述が一対一でアセンブラに落ちる」という理解も全く不正確であり、Cの仕様もコンパイラもそのようなことは保証していない
というか、それが保証されるなら最適化という概念自体が存在しない
そこを理解していない時点で、お前は妥当な使い方ができていない

>>506-507
>>509-510
あちこちに誤りがある
多分全て指摘はできないが、まずC言語の仕様に即しているかどうか検証することは可能
なので「その時その環境で動作が正しい事しか保証出来ない」は誤り

その誤りを隠すために
>「あらゆる環境で、(未来含めた)あらゆるコンパイラで、このコードは、動作する」事を保証出来ると思うのなら
という無茶苦茶な前提を追加しているが、当たり前だがコンパイラと環境が仕様に準拠していない場合を含めているのは詭弁である
JavaScriptも実行環境にバグがあれば正しく動作しないのに、恣意的に無視しているためである

> malloc/callocのどちらを使うかはプログラマに任せてある
それは両方規格に含まれているため、規格に含まれていない記述を正当化するための例に用いることはできない

>>512-513
>>515
また、メモリ上の配置はコンパイラによって自由に変更されるため、そのような挙動はごく少数のコンパイラの限られたオプション指定で発生する事象に過ぎず、何ら保証されない
Javaの話は無関係であって、そもそも物理配列であることとは直接的に関係がない

> たまたまではなく、そのコードで動かない環境は多分無い
などと言い切っているが、1バイトのサイズすら環境によって異なるのにそんなコードがどの環境でも動くと想定する方がおかしい
どうせ同じアーキテクチャの同じコンパイラにしか触れてきていないのだろう、ということが丸わかり

> それでも気に入らなければ、該当部分を書き直すか、そもそもCコード自体を流用しなければいい
これも異なる
そもそも該当部分が問題であることを明示しなければ、そのような修正は困難であるし、問題がないと言い張るということはどうせ何も書いていないのも明らか

全体的に見て、あまりにも誤りと矛盾が多すぎてお話にならない

>>504
> デタラメな使い方でもバグがない事を検出してくれ
そんなことは言っていない
「デタラメな使い方が正しいんだ！」と主張するバカげた行為をやめろと言っているだけ

>>509
未定義動作になるコードだが動くというものを採用してはならないのではなくて、それは何ら安全性が保障されない、アーキテクチャもコンパイラもlibcも、種類どころかバージョンすら変更できないコードだということを理解して、いつでも適切に破棄できるようにしておかなければならないという話
そうでなければ不具合の元にしかならない
それができないお前みたいな奴がいるから、Rustを使えと言われてるわけ

>>515
お前みたいなアホが「今動く」と「正しい」を勘違いして負債を残し続けた結果、C言語の既存資産は危険なものという扱いになってきている
それを堂々と他人に正しいやり方みたいに吹聴して被害を拡大させるのはやめろってこと

>>504
C言語のコンパイラが必ずアセンブリ言語を出力するという事実はない
ClangはLLVM IRを出力する設計になっている
また、前提として前後のコードと合わせて最適化が施されるため、アーキテクチャやコンパイラ、バージョン、最適化のオプションによって出力されるアセンブリ言語やIRの処理も異なる
C言語仕様において、保証されていない挙動に関してどのように実装するかはコンパイラに任されている

>>503
それは全くその通りで、当然規格外のコードは原則として再利用できない

>>505
> 必要であれば言語仕様外の挙動に依存することはそれなりにあるのも正しいと思う
> 低レイヤの細部を全く制御しないなら C を使う意味がない
の2文が論理的に結びついていない
C言語の仕様の範囲内でも低レイヤの細部を制御する機能は多数提供されている
それ以外は同意

>>516-518
>>515の通り。気に入らないならC使わないのが最適解だ。

ID:EKW8EhdF0
まだ書き込み中だったのはすまんね、もうちょっと待てばよかった。
でも結論は同じ、>>515の通りで、お前はC使わないのが最適解だ。

>>509-510
これはC言語の話ではなくてRustの話になるのでこの1レスに留めるが、>>520-521でも言ったように、今動くコードと正しく書けているコードの区別がつかない人間のせいで、大量の問題のあるコードが生産されたので、Rustではunsafeブロックの外では未定義動作を書けないようになっている

また、Rustのコードは仕様に忠実であることが保証され、かつ明示的に不変/可変やポインタのエイリアシングの有無を扱えるため、最適化が行いやすく高速なプログラムを生成できる、良いコードになる場合が多い
C言語の場合はこのような保証がないために、最適化が行えないというケースも多い

更に、Rustは別にコンパイラが安全性を検証できないコードを全否定しておらず、unsafeブロックで明示的にプログラマの責任で記述することが可能である
そのため実現できない処理があるというような主張も誤りである

>>524-525
C言語が気に入らないのではなく、>>521でも書いたように
> お前みたいなアホが「今動く」と「正しい」を勘違いして負債を残し続けた結果、C言語の既存資産は危険なものという扱いになってきている
> それを堂々と他人に正しいやり方みたいに吹聴して被害を拡大させるのはやめろってこと
を言っている
それができないならお前こそCを使うのをやめた方がいい

>>524-525
これも>>520でも書いたが、
> 未定義動作になるコードだが動くというものを採用してはならないのではなくて、それは何ら安全性が保障されない、アーキテクチャもコンパイラもlibcも、種類どころかバージョンすら変更できないコードだということを理解して、いつでも適切に破棄できるようにしておかなければならないという話
> そうでなければ不具合の元にしかならない
> それができないお前みたいな奴がいるから、Rustを使えと言われてるわけ
お前みたいにコードをちゃんと検証せずになんとなく動いたからで組み込む人間は、Cを書かない方がいい

C言語は「ふいんき」（注: あえてこのように書いた）でこねくり回して書く言語ではなく、危険性を理解して検証しながら書く必要がある
「なんとなく動いてるー」は検証とは言えず、なぜ動くかをちゃんと説明できなければならないのであって、「物理配列だから」のような雑な理解で未定義のコードを他人に見せびらかし、正しいと主張するような人間が書いていいものではない
それは脆弱性や不具合を減らそうという、ソフトウェア開発の基本的な考え方とまるっきり逆行している

>>526-529
ならお前はRust使って、それで終わりでいいじゃん。
C使いたい奴はC使わせておけばいいだけだろ。
Rust界隈って(意識高い系なので多様性を大いに認めることになってるはずなんだが、)
Rustしか認めない、多様性なんて死ねな人達でしたっけ？(棒)

>>530
全く読まずにケンカ売ってるのはわかった
お前みたいなアホがCを書くから問題になってるんだって言ってるだろ
Cを書きたいならちゃんと必要な知識くらい学んで頭を最低限使えって言ってるんだよ
頭悪いとわかんないかもしれないが

>>530
別にRustを書けって言ってるんじゃなくて、お前みたいなアホの被害を防ぐために規則を導入したのがRustだって言ってるんだよ
Cを書きたいなら書けばいいけど、お前みたいに頭も使わず「ふいんき」で書いてるような奴はCプログラマとして論外なの

バカは条件を読まないから困る
こういう奴が問題を増やすから苦労するんだよな

>>530
人を見下すのは好きだけど自分が見下されるようなことをやってる自覚はないんだな
モノ考えてから発言しろよ

>>530
「お前はC言語を使わないほうがいい」とかイキってたけど、お前みたいに頭も使わず「ふいんき」で書いてるような奴が書くふわふわ言語だとでも勘違いしてるのか？
そうならPythonでも書いてろよマヌケ

>>511
ホンマそれ
条件すらまともに読めない奴が未定義動作モリモリのコード書くとか悪夢でしかない

>>531-536
典型的なRust信者やね。
良くも悪くも、仕様が後から追認されたりする文化なのは事実で、合わなければ他言語使えばいいだけ。

どうせお前含めて、大概の連中が書くのは糞コードだ。
でも、同様の事をやるなら同様のコードが必要になるから、ゼロから書くよりはマシなので流用される。
勿論流用側が精査し、全部捨てても、一部修正でも、丸々全部そのままでもいい。これで回ってる。
品質を保証するのは流用側であって、流用元ではない。
俺様が流用する時の為に常に完璧で俺様にピッタリなコードを書いておけ、なんて事は成立しない。
ああ、Rustでは成立してるんでしたっけ？ならそっちでどうぞ。

>>537
テスターが頑張ってるからコード書く俺はどれだけひどくてもいいって他責思考なのね、了解
みんな、こいつの真似だけはしちゃダメだぞｗ

>>537
お前、自分が読めないくらい高度なコードのこと「糞コード」って呼んでんのなｗ
お前が勉強してないのも他人のせいだってかｗｗ

>>537
> 俺様が流用する時の為に常に完璧で俺様にピッタリなコードを書いておけ、なんて事は成立しない
また書いてないことを勝手に読んで藁人形論法を始めたな
自分が正しい、お前は間違ってるって言うためならいくらでも捏造、相手が悪いから俺は悪くないんだ！ｗ

>>537
お前が言ってるのは「ゴミしか書いてないから流用する奴が悪い」な
それは自由だけど、ちゃんと「ゴミです」って書いてくれないとこっちも手間取られて迷惑なのよｗ

>>537
そのゴミをここで放流するのやめてねｗ
自分のPCの中に留めておいてくださいｗｗ

>>537でちゃんと「俺はゴミしか書かないし勉強もしないし全責任はテスターに負わせる、俺が読めない高度なコードを書く奴はクソ」と言ってくれたからもうまともに相手はしないわ
そう思うのは勝手にどうぞ、でもそれを正しいと押し付けてくるのはやめてね

今のプログラムなんて、ほぼみんな
たまたま動いているように見えるだけで、
未来永劫バグなして動き続けるなんて
誰も保証しないと思う

>>544 そんなこと保証しろって言ってる奴は君の妄想の中にしかいないぞ
明らかに動かなくなることがわかり切ってるような、偶然動いてるだけのコードを堂々と持ってくんなって言われてるだけ