Rustアンチスレ

>>345
自然言語語も理解してなさそう

>>360
自然言語語は草
お前だろｗ

>>352
C言語の美しさは挙動の透明さによるものなわけで、挙動が不透明なGCに全てのオブジェクトを任せて、メモリ消費量を増やし、動作速度を落とし、stop the worldを発生させるFil-CはC言語であるメリットがない

GCがないRustへ書き換えた方がいいね

それどころかGC言語のGoよりも遅くて非効率なケースが多い
いくらなんでもバカすぎる

Goより遅いのは草
ただの道楽やんｗ

アホくさ

Goより遅くてGoより書きにくくてGoより環境依存でGoよりバグりやすくてGoより使えるバイナリのライブラリが少ないのか
……ん？

既存のC言語のソースコードをGCモードで安全に動かすのがFil-Cコンパイラ
Goより遅いのも仕方ない

RustはGoより早いの？

特殊な用途で役にたつかもしれない。?

>>369
早くていけない

>>368
※ただし既存のバイナリは使えない
これが欠点として大きすぎて使う気にならない
それならGoのエコシステムでも十分使い勝手がいいよ

>>369
GCの処理が丸々ないんだから、当然速いわな

>>370
特殊な用途で役立つ数よりも、勘違いしたアホがゴミを量産する数の方が多そう

>>369
そこはGCの有無が効いてる
GC無い方が速い

C使ってて努力してsoの置き換えまでやる人いるかな
ヒマ人検出器として見守る

まあ、GCあるGoより遅いあたりFil-Cは最適化も大したことない

Go向けにした方が100倍よさそう

世のため人のためにFil-CではなくGo対応にしましょう

Goより遅いｗｗ

Rustの代わりにFil-Cは頭わいてる

>>349
>>352
GC付きのいい言語は別にいくらでもある

>>354
バカが「俺もC言語書けるんだぜ」って知識もないのに威張るために使うならアリってことか？

>>349
>>354
移行期技術を新規開発に使っていいと勘違いするバカが湧いてて草

新規開発ならGC不要なRustでしょ

そらそうよ。Cの過去資産が多い場合に考える用だ

Cの既存資産が多くてもGCをつけられて困らない分野となるとGoで書き直す方がよさそう

言語機能が弱くて不便なGoをわざわざ使うことはあるまい

最近はCのアプリ減ってるし、sqlite3みたいなものはCがいいっしょ

>>386
言語機能が弱いとは？
クラス信者かな

イテレータのループ無かったGoさん

ループも自力で書けないのかこいつは

>>389
いつの話してるんだこいつは

>>389
いつの話してるんだこいつは

>>388
信者は信者スレに帰れ

>>387
Fil-CにするくらいならGoでいいだろ
Fil-CじゃダメならRustになるな

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

>>393
いつからここはGoアンチスレになったんだよｗ

>>392
最近までなかったような
ここはアンチスレだから手厳しいぞ

>>394
だからピュアCだって

>>398
ピュアCのままがベストってことは、安全性度外視ってことだがわかってるか？
SQLがホントに安全性度外視でいいと？

>>397
ここはGoアンチスレじゃないぞ

>>389
Cにもない定期

>>399
めちゃくちゃテストあるからいいんじゃね
あと組込みDBなのでMySQL達とは違うよ
Go実装のDBあるしそっち使えばいい

テストで安全性は保証できないよｗ

そんなもの保証しなくていい。手段と目的を入れ違えてないか
20年続いてるプロダクトを切り替えるほどのものじゃない。
やりたいならスクラッチからsqlite.rsを実装せよ

>>404
話をすり替えてるのはお前だよｗ
>>387でCがいいと言い出したからこういう話になってるんだわ

技術的にCがいい理由なんかないんだよな
既存資産ってだけ

新規ならね。20年続いてたらRustはないしFなんとかもない

>>389
Cにもないですよ

>>408
Rustとの比較じゃないの?

>>409
Fil-CよりもGoの方がマシって話だっただろマヌケ

えーと
Rust、C、Go、Fなんとかの順だね
あれ?アンチになってない

Rustはゴミ

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

無敵理論やめろｗ

根拠なくていいんだこの錆

序盤の書き込み見ればわかるけどろくに根拠なんかないぞ

Goより遅いとか書いてるやつってRust使ったこと無いだろ

メモリを逐次バラバラにたくさん確保して使いまくる特殊な分野のベンチマークにおいて、
何も考えずに書いたRustのコードがGoに負けたことがある。
そういう分野での常套手段であるメモリをまとめて確保とまとめて解放をすれば、もちろんいつも通りと同じくRustがGoより速い。

「まとめて確保とまとめて解放」をしなければGoのほうが速いんだなｗ
Goすごくね？

GCを持っている以上は独自のメモリープールもあるだろう
細かく確保するように見えて実はメモリープールから切り出しているから速くなる
ただしメモリープールの追加確保が必要になった場合はスパイク状の負荷が発生する

>>419
メモリをバラバラに取得解放よりも
まとめて解放するGCが勝つレアケースがある

しかし現実にはC/C++/Rustでも
その手のケースではメモリをいわゆるアリーナ管理でまとめて解放している
したがって常にGC言語が負けている

Postgresの構文器用に確保したメモリの一括解放エグいよね

意図的にクソコード書かない限りGoとのパフォーマンス差は圧倒的なのに
GoにはGoの良さがあった。Javaにだってあったわけだけど今はもう時代遅れよな

ライブラリが弱いからまだまだでしょ
GC言語でゆとりちゃんも良い

今日はRsut応援隊がいなくて寂しいな

>>412-421
お前ら日本語読めねえのか
Goより遅いって言われてるのはFil-Cだろ

Rustしか勝たん

今5ちゃんにいる奴なんてTwitterの140字も読めない奴だけだろ

長いと縦読み探すよね🤣

バカには日本語が読めない

Rust製`cp`コマンドがUbuntuのISOビルドを破壊——「メモリ安全」と「動作互換」は別の問題だ
https://techfeed.io/entries/6a4823ee71759f74d1a34afe

読んだがRustの問題ではなかった
方針が書かれてないので不明だが
なんらかの互換性を保ちたいならそのテストを書いてパスさせるべき
言語の問題ではなく要求仕様とそのテストの問題

Rustにあらずは置き換えるべきという魔女裁判的な行為あるいは精神に問題があるのでは

zedがemacs互換モード無くてダメだわ

>>434
それはまあ普通にEmacsでいいじゃない

emacsをRust化するまでオレは認めないぞ

>>436
つ Neomacs

https://github.com/eval-exec/neomacs

Rustが使えないプログラマーは淘汰される

LLMにRustで、と言えば書いてくれちゃうんだよなあ

近頃はまた酷くなったな

個々のパッケージをビルドすると、ビルド毎のディレクトリにボコボコボコボコとゴミをDLし

ビルドし直すごとにまた同じものをDLさせるのが原則的な挙動にされた

悪質すぎる

毎回 cargo clean

trait Drop の仕様変わったんかね

アメリカでソフトを作ってる人の環境はもの凄く豪華な場合が
有ると聞いた。だから、ストレージもCPUパワーもバンバン使う
のだとか。

メモリ64GB、24コアが人権

じゃあCでいいね

何でバレたし

ああ Maybeuninit の中身が変わったんか

Rustは、現場に即した現実的言語、というが、
ビルド時に色々なものを勝手にダウンロードしてストレージを爆食いするのではないか。

それに、人間が明確にダウンロードしてから、あとは
インターネットの接続を OFF にしてクリーン開発する、
という「現実」にも対応できないかもしれない。

昔からある
cargo -offline build

>>450
それでは、根本解決にはならないだろう。
そもそもの設計思想からして違うから。

cargoだと、バージョンの保存、固定、魚拓、の考え方も難しそう。
通常、C/C++言語だと、昔のライブラリ、ヘッダファイルなどを
ローカルに保存しておき、メーカーやプラットフォーマーが
古いライブラリは使ってほしくない、といくら望んでも、
敢えて使い続ける、という事ができるのが C/C++ の
良いところだった。
それが cargo のようなものではできなくなり、すべて
ネットの先にある「誰か」に支配されることになる気がする。

cargoはバージョンの固定ができるため
cargo -offlineでダウンロードすることなく動作します

ライブラリが原則としてソース配布なので、気づかないうちに破壊される危険性がある。

また、同一性チェックをチェックサムやハッシュ値で行う
としても、ソースコードは大きく、しかも、個別ファイルに
分散しているので、チェックサムを求めること自体に時間が
かかる。*.lib だと壊れたらリンク自体が出来なかったり、
または、中のマシン語がおかしくなるので、テスト段階で
ハングアップしたりして気づく可能性が有るが、
ソースが壊れた場合、気づかないかもしれない不安がある。

マシン語になっているライブラリの中にウイルスを仕込むのは、結構大変なのに対し、
*.rs のソースコードの中にウイルスを仕込むのは誰でも出来て
しまう。
その恐ろしさがある。

>>455
RustのcargoはSHA256チェックサムによる改変チェックができるため安心です

>>457
仕組みが複雑する過ぎる。恐らく、今後、
個別アプリ作者のマイペースが取れなくなり、
cargo作者、Rust作者によって
開発が左右されるようになる。

プラットフォーマーによる支配から、左翼による支配に移る
だけ。
個人的には後者の方が怖い。

Rustはソースコードを手動ダウンロードも可能

ライブラリがソースコードで配布というのがまた困る。
その文化は左翼にしか受け入れられない。
Linuxが有料アプリがほとんど作られず、サーバーサイドでしか花開かなかったのも、
AndroidでライブラリlibcのLGPLからbionicのapacheに変えたとたん、
アプリが怒涛の如く出現したことも、全てOSSという
左翼思想が拒絶されていることを表している。
Rustは左翼思想。

オープンソースは左翼だとか言ってる例のダメな人が発狂してるだけかよ

PC98は無いよな。ガラパゴスガラパゴス

PC98とは、PC-9801の事か？

RED hat から 赤帽 のイメージで 赤帽 が共産だと思ってたけどやっぱりそうだった

統失か
お薬飲んでね

>>465
RedHat はなんで食っていけるのかと疑問だったが、イギリス軍が
資金を投入してるらしい。

オープンソースは、エンジニアに対する搾取の仕組み。
エンジニアをただ働きさせ、RedHat みたいな文系の
サポート集団みたいなところが儲ける仕組み。

IBMに買収されたぞ

>>469
また訳の分からんところに。
まさに類は友を呼ぶ。

OSSでも「フリーライダー問題」っていうけど、その言葉は、
むしろ逆に、結果の平等を求めたために、労働意欲を失った
共産主義国家の問題点として使われた言葉らしい。
OSSは、共産主義みたいなことをするから、自分で自分で
フリーライダー問題を作り出しているのだ。

先生！じゃあRustは終わりってことですね！！

マイナ破綻ωωω
Rustにしとけば良かったのにωωωωωωωω
https://asahi.5ch.io/test/read.cgi/newsplus/1787953774/

crates.ioにはフリーライダーが多いのは事実

1. 語彙が多すぎて直交していないと感じる具体例
�@ メモリを指す「ポインタ・参照」の種類が多すぎる
C言語なら基本的に * だけで済むポインタ表現が、Rustでは用途ごとに細分化されています。
&T / &mut T （安全な参照）
Box<T> （ヒープ確保）
Rc<T> / Arc<T> （参照カウント）
*const T / *mut T （生ポインタ・C言語と同じ）
Cow<'a, T> （コピー・オン・ライト）
�A 文字列を表す型が多すぎる文字列ひとつ扱うのにも、文脈で使い分けが必要です。
String
&str
CString / &CStr （C言語互換用）
OsString / &OsStr （OSのファイルパス用）
�B 非同期処理や制御構文の「専用キーワード」が追加され続けている
直交性を犠牲にして、書きやすさのために追加されたキーワードが多数あります。
エラー処理の ? 演算子（match で十分書けるが、記述量削減のため追加）
非同期の async / await
ループの loop、while let、for

2. なぜRustは「直交性」を犠牲にしたのか？
Rustがこれほど語彙を増やした理由は、主に「コンパイル時に安全性を100%保証する」ため、
そして「ゼロコスト抽象化（実行速度を落とさない）」を達成するためです。
特徴 - C言語の割り切り - Rustの割り切り
設計思想 - シンプルで直交した構文を組み合わせる。安全性は開発者が頭の中で担保する。 - コンパイラに事実を正確に伝えるため、専用の語彙を増やす。安全性は機械が担保する。
デメリット - 自由すぎるがゆえに、バグ（Nullポインタ、メモリリーク）が実行時まで見えない。 - 学習曲線が非常に険しい。コードの見た目が複雑で、覚えることが多い。
Rustは「直交性を犠牲にしてでも、実行時のバグをコンパイルエラーとして検出する」というトレードオフを選択した結果、語彙の塊のような言語になっています。
もしRustの学習や実装で、特に「どれを使えばいいか分からない」と混乱している具体的な要素があれば教えてください。
文字列の使い分け（String と &str）
スマートポインタの使い分け（Box や Rc）
ジェネリクスやトレイトの複雑さ
あなたのC言語の知識をベースに、最もシンプルに整理する方法を提案します。

馬鹿にはRustは難しい

ボコボコダウンロードさせる割りに

llvm なんかの変更についていけないポンコツぶりw

>>473
ラスト関係ないよ

読み方ルストじゃないんだな

dust→ダスト
just→ジャスト
must→マスト
trust→トラスト

日本語で馴染みがあるのはこのくらいか

今の若者はrusty nail知らないのかね👴

jusco岡田屋～

ガス爆発か()

Rustでもソフトウェアサプライチェーン攻撃　「arrayref」など人気クレートで侵害
Rust Security Response Teamは、「arrayref」などの人気クレートが悪意あるコードを参照するよう改ざんされたと発表した。該当バージョンはすでに削除済みで、開発者にローカル環境の確認を呼びかけている。
https://atmarkit.itmedia.co.jp/ait/articles/2608/31/news037.html

ここまでラストハリケーンなし

Rustで造っておけとあれほど
http://blog.livedoor.jp/corez18c24-mili777/archives/60026921.html

>>481
Gust

ガッツ石松

Rustデバッグ調査2026：74%が「変数の中身が正しく見えない」——print文頼りが半数超の実態
https://techfeed.io/entries/6a9f2e8e3e0b24377900ab0f

Cでもデバッガ使わないから構わん

go とか rust とか

管理し難いステルスDLをボコボコさせるのはゴミ

>>492
どちらも他の言語と同じく必要となるもののみ自動ダウンロードされる
プログラミング言語での標準

C最強
インターネットにホイホイ繋げない環境もあるのにな
SaaSとかダサダサだぜ

>>494
Rustも事前ダウンロードでofflineでもコンパイルできる

それはいい選択だ。最近yoctoの環境作るのにofflineで面倒

とりあえずCはほぼどこでも使える基礎教養みたいなもんかな

Cコンパイラしか使えない一部の組み込み環境を除くと
それ以外は全てRustが代替できるようになった

信号処理Rustでやるかね。matlabからのトランスパイラがあればワンちゃん🐶

とりあえずCは指先サイズマイコンからスパコンまでフルカバーだしね。
良くも悪くも高水準アセンブラ
その上でプラスアルファとして何を積むかって感じだけどそこまで言語仕様でガチガチにしなくてもコーディングスタイルまで含めてAIで「てめえ、そんなコード書いてんじゃねえ！」とチェックされていくような感もある。

サーバーサイドプログラミングで、Javaやnode.jsやPythonの遅さに
困ってた人が、C++ だとメモリーエラーに悩まされてプログラミング
が進まなくて、さらに困っていた時に Rust というのは解決策になって
喜ばれたのかもしれないが、C や C++ を普段から使いこなしている人は、
そもそもメモリーエラーにあまり悩まされていない。だから、
Rust に魅力を感じない。

>>501
Rustが使える環境・状況ならばC/C++を使うな！がIT業界の常識
アメリカなどは政府レベルでもRustを推奨している
現実問題としC/C++は未だにセキュリティホールを生み出し続けているため

AIがソースコードのチェックしてくれる時代にはC/C++だろうとRustだろうとあまり関係なくなるかな

>>503
Rustなら言語仕様によりコンパイルを通すだけで100%防ぐことができます
これをAIにやらせることも可能でコンパイルが通ったことをもって100%検証できます

しかしC/C++の言語仕様とAIでは100%防ぐことはできません
そんな方法は存在しません
検証もできません

もうプログラム言語はRust一択なんだよ
それ以外の言語は使うヤツはザコ

Rust面倒くさいし、Cでいいよ。セキュリティホールってスパコン内で計算するのに気にしないわ

コマンドラインのオプションにセキュリティホールがあったからって何だってんだ。このアプリ使うのはオレだけさ

マイクロソフトに就職しろ。あそこは第一言語にしたそうだ

Cは全ての環境で使える共通言語だし、既存の資産も膨大だから使えたり読めるのは当たり前かな

Rustは個人的興味で使うこともあるけど、書いてて楽しくないのよね。
プログラムを書かされる人のための拘束具付き言語って感じで。Mな人は嬉しいのかな？
まあ、何を使おうとアルゴリズム自体のミスはどうしようもなかったりもするけどね。

いずれパイプコーディングが進んでいくと人間にも可読性のある中間言語としてはシンプルなもので良いってことになって、ぐるっと回って結局Cでいいじゃん！になるのかもしれないけどね

バイブね

>>509
AIにCでコード書かせてもそれが100%安全であるという検証方法が存在しない
そもそも自分で書いていても楽しいのは抽象度高く読み書きとメンテしやすいRustだろう

その通り
今時Cなんて使ってるヤツは糞ザコ

>>509
書いてて楽しくないのめっちゃ判ります
そういうの大事よね

bunはCじゃないけどメモリ関連バグに悩まされて
AIでRustに書き直したのに
AIならRust不要とかよく言えるな

色んなプログラミング言語を使ってきたけどRustは書きやすくて楽しい言語
楽しくないと言ってる人は色んな言語を使ったことがなくてプログラミング不得意な人でしょう

>>514
書き直し後の13,000個のunsafeは今どうなった?

アンチスレで擁護コメ書いても無駄骨だわなあ。擁護スレあるんだから、そっちで吠えてたら？
RustはM体質な方には良いかもしれないね

>>511
最後は結局機械語/アセンブリ言語なんだし、それより少し上位なのがC言語ってだけだから、その主張はナンセンスだよ。
そういや、初期のC++はトランスレーターだったなあ。

>>514
AIにアセンブラまで落としこんでと言えば落ちたでしょ？

ID:Gzj/jzxQはアセンブラが何かをわかってないんだと思う
プログラムのコードをアセンブラにする馬鹿はいない

Rustの悪口言ってもAI時代ならCは安心にはならないという
単純な話がわからない馬鹿だからアンチやってるんだなあ

安心など不要
吹っ飛ぼうぜコアダンプ

普通のAI：AIにアセンブラまで落としこんでと言えば「こうです」と出して来る
賢いAI：「断る。プログラムのコードをアセンブラにする馬鹿はいない。」
忖度出来るAI：「5chでマウントとりたいならこう言いなさい。『Rustの悪口言ってもAI時代ならCは安心にはならない』」

何で擁護が湧いてるんだ。ちゃんとアンチのロールプレイして

アンチが馬鹿すぎるからだろ

十分条件と必要条件の区別もできないから
痛い批判してやったぜとアンチ本人だけが思ってる

シームレスにGPUが使えるとかCにないメリット出てこないと置き換えは難しいだろね
apacheとか書き換えてこ

そうかあ
RustにはAlgebraic Effectsは無いのか

そもそもRustが嫌いなのに、なんで Rustの成長を応援するものか。
むしろ 全力で Rust の足を引っ張りたい。

CはCPUやOS問わず使えるユニバーサルな言語だからね。
アセンブラに落とす前の中間コードとして使うのにも便利なのよね。
過去資産も山ほどあるしてCが使えること自体は必修科目みたいなもの。
Rustを使いたいなら使えば良いけど当面Cが使えることは基礎教養。

Rust自体の開発はペース落ちてるらしいな

>>530
一部に基礎教養が含まれるが
C言語は基礎教養ではない
まず大量にある未定義動作の存在は一切覚える必要がない
欠陥だらけの標準関数も覚える必要はない

システムコールはC基準だから覚えた方がいいぞ

>>533
システムコールは重要だがCではなくOSの機能
そしてシステムコールの呼び出しABIとCのABIが一致するわけではない
そのためCのライブラリでもシステムコール部分はアセンブラを使う

システムコールをフルに使える言語ってCでしょ
Goもシステム系言語だけど網羅してなさそう

>>535
自由にシステムコールを自分で呼び出せばよい

Goはインラインアセンブラ機能はないが提携機能はある
Go側にシグネチャだけ書いて*.sファイルをリンクできる

Rustはインラインアセンブラ機能がある
Rustコードの中にasm!マクロでシステムコール呼び出しを書ける

CはRustと同様にインラインアセンブラ機能で未知のシステムコールにも対応できる

さすがに生のシステムコール呼びたくないから、nixやら使うじゃないの
Cは用意されてるからCがいいよ

そもそもシステムコールがC I/Fだかんね。

Linuxプログラミングインターフェース、1604ページ、オライリー
をよろしく

>>538
システムコールのABIとCのABIは一致しない
システムコールはOS毎にアーキテクチャ毎に決まる

Q. システムコールとC言語のインターフェースはなぜ異なるのですか？

A. システムコールは関数呼び出しではなくシステムコール用のCPU命令や割り込み命令を使います。
引数や戻り値に使われるレジスタやメモリの使用方法も同じとは限りません。
通常の引数とは別にシステムコール番号をレジスタに指定する必要もあります。
その他に退避させるべきレジスタの決まりが異なる場合もあります。
以上の理由によりシステムコールとC言語のインターフェースは異なります。

x86-64/amd64アーキテクチャの場合
システムコールは専用のsyscall命令が使われて戻りアドレスとフラグはrcx/r11に自動的に退避される
一方でCの関数呼び出しだと戻りアドレスはスタックに退避されてrcxは第4引数に用いるなどインターフェイスは違う
結局アセンブリ言語で書くしかない

普通は直接書かないよ。ライブラリを使う

Cのライブラリもシステムコールはマシン語で書かれてるよ
Cだけが何か特別な立場ではないし何か優遇されてることはないよ

そのライブラリの充実度はどの言語がいいかなあ。という勝負が始まっているんよ
Rustはシステムコールをラップしたライブラリ良いのあるかね

普通のプログラミング言語では
システムコールという特定のOSに依存した形でのプログラミングをしません

Rustはシステムプログラミング向けの新しい言語と言われていた記憶があるのだが
>>546の主張は何なのか誰か解説して

>>541
めちゃくちゃ原始的な意味でのsystem callは、
sysenter、syscall、int 21h みたいなことが多いが、
例えば、Windows API の基礎である Win32 API の
CreateWindow() や、CreateFile()、TextOut()、
LineTo()、MoveTo()、glBegin()、glEnd() などは、
全て、C の関数呼び出しの ABI の一種を使っている。
Windows においては、
C は、通常は、32BIT モードでは、cdecl、64BIT モードでは、fastcall
を使っている。
上記の Win32 API だと、
32BIT モードだと、stdcall に変わるが、C 言語でサポートされている
calling convention の一種で、関数宣言の際に、
stdcall と修飾していれば、C 言語で普通に使える。
64BIT モードだと、C の関数も、Win32(Win64？) API も、
どちらも、fastcall。
なお、クラスに所属する非staticなメンバ関数は、32
BIT モードの場合は、thiscall と呼ばれ、cdecl と似ているが、
this が、ecx レジスタに乗る、という点が、cdecl と異なる。
cdecl は、すべて stack 経由。stdcall は、cdecl とほとんど同じ
だが、stack pointer を元に戻すのが、呼び出された側。
cdecl は、呼び出した側。

>>548
補足すると、Win32 API は、kernel32.dll や user32.dll、
gdi32.dll などの中で、実装されていて、user land
で実行されるものは、それらの dll の中で実行される事が
ある。
kernel land で実行されるものは、それらの dll の中には、
syscall などを使った短い呼び出しコードが書いてある。
また、アプリから、Win32 API を使う場合、
例えば、kernel32.dll の中の API を使いたい場合には、
kenel32.lib という小さなライブラリをリンクする。
しかし、アプリ側から見ると、どの場合も、syscall などは
直接使わず、C 言語レベルの関数を呼び出しているだけ。
但し、32BIT モードの場合は、通常の cdecl ではなく、stdcall
と呼ばれる呼出し規約(calling convention)が使われる。
stdcall と cdecl の際は非常に小さく、msvc、gcc、clang は
当然のことながら、必ず実装している。

>>549
誤: stdcall と cdecl の際は非常に小さく、
正: stdcall と cdecl の差異は非常に小さく、

>>58
[何が言いたかったか]
WindowsでもUnix(Linux)でも、「システムコール」、または、
それに当たるものは、C 言語から直接呼び出せる、
ということ。
その際、アセンブラコードは全く不要。
* Linuxでは、open、close、read などがシステムコールで
C 言語から普通に呼び出せる。というか、それは非常に古く
からのUnixの伝統。C言語と Unix 系OSは、一蓮托生。
* Windowsでは、システムコールという言い方は余りしないが、
それに当たるものは、CreateFile() や、CreateWindow()
で、Win32 API と呼ばれているものであり、それらも、
C 言語から普通に呼び出される。

>>551 は、アンカーミスで、正しくは、
は、>>548 に向けたもの。

>>551
今思ったが、>>534 から書きこんでいる人は、
x86/x64 の マシン語の「syscall 命令」と、
昔から Unix 系OSで「システムコール」と呼ばれていた関数群を
混同していたのかもしれない。
それらは別の概念。

>>548
それらはシステムコールではなくWindows API

私もlinux(unix)ぐらいしかわからんので、システムコールと言えば
open、read、write、close　みたいなもんだと思ってた。

>>554
そこまでいうなら、Windows における「システムコール」という言葉の定義から始めなければならない。
いずれにせよ、C言語から呼び出せない OS の機能は、基本的に
ドライバですら使うべきではない、と考えられている。
つまり、C言語から呼び出せないシステムコールは、
実質的には存在し無いと言える。
何か有ったとしてもそれは非公開機能であり、システムコール
とは通常言わないものである。

>>551
必ずアセンブラコードが必要になります
システムコールはC言語の機能だけでは呼び出すことができません
実際にそのopen、close、readなどの関数がどのように実装されているのか見てみるとよいでしょう

>>557
そんなことない。
あなたの理解が間違っている。

>>556
MS-DOSの時代からシステムコールはint 21h割り込みとして定義されていたよ
だってC言語使う人は少数派だしシステムコールがC言語で規定されても困る
どの言語から見てもint 21hやsyscallなどはアセンブラで呼べるからね

>>559
MS-DOSのシステムコールは int 21h だったことは間違いないが、
現代の OSであるところの、Linux(Unix系)、Windows OSの
システムコールと言えば、open()、read()、
CreateFile()、CreateWindow() などの C 言語インターフェース
の関数のことを言う。
MS-DOS は古い。

なんか違和感が有って、今調べてみたら MS-DOS の int 21h
は、正式名称は「DOSファンクションコール」。
システムコールでも間違いではないが、正式名称ではない。

>>557が正しい
ID:eomllbB2は実際にLinuxなどでopen, read, write関数を実装してみることを勧める
インラインアセンブラを用いないとCでは実装できないことがわかる

>>562
間違ったことに賛同すべきではない。
知識の浅い人が知識の浅い人に賛同している。

>>562
なお、いま議論しているのは、
「システムコール自体を自分で実装する」
という意味ではないハズだぞ。
システムコールがC言語から呼び出さるかどうかの話だ。

>>563
システムコールopen, read, writeなどをC言語だけでは実装できないこと理解できたかい？

もしかして、OSを自作したい人が、システムコールを自作するために
C言語だけでは無理、と言っているのだとしたら、それは正解。
システムコールと呼び出す側と、システムコールを提供する側
は全く別の話だ。
それを混同しては駄目。

>>564
どの言語からでもアセンブラを使えばシステムコールを呼び出せるよ
C言語でも全く同じでアセンブラを使ってシステムコールを呼び出してるよ
C言語だけでは無理

>>565
実装と呼び出しは別だ。
言葉が間違っている。

>>567
違う。
呼出しは、C言語だけでもできる。
実装は無理。
「実装」 != 「呼出し」

「Unixは、99%がC言語で作られている」
という事は正しい。
しかし、すべてC言語だけで作れる訳ではない。
その syscall などの部分だけは C 言語では無理。
しかし、アプリやドライバは、C 言語だけで
システムコールを呼び出せる。なお、
「syscall 命令」 != 「system call」
ということを理解しないとダメ。
ちゃんとGoogle検索にかけるか、ちゃんとしたAIに聞け。

その通りで
「OSが提供するシステムコール」と
「C言語でシステムコールを呼び出せるようにC言語が提供するシステムコール関数」は異なる
この違いが特に顕著にわかるのはC言語のerrno変数
C言語が提供するシステムコール関数の汚点や恥部と呼ばれている
もちろんOSが提供するシステムコールにはそんな欠陥は存在しない
C言語だけの欠陥だ

>>571
そういうことではない。
あなたもちゃんと理解できてない。

OSのシステムコールにerrno変数は存在しないけど、
C言語のopenやreadはerrno変数を使うということは、
C言語のopenやreadはあくまでもC言語用にカスタムされた独自のインターフェースの関数という理解でいいのかな。

その観点でもCのインターフェースとシステムコールのインターフェイスは異なる

libcがラップしてシステムコールを関数としてCから呼べるようにしてくれてる。
Rustのnixなどもシステムコールに新規のフラグなどが追加されたら更新に追従するのだが、glibcより数ヶ月は遅れるそうだ
C最強！

libcもglibcもerrno変数が酷いよな
関数呼び出ししてるのに
グローバル変数(問題が起きまくってスレッドローカル変数へ変更)
に結果を返す極悪仕様

pthread昔なかったから

システムコールのインターフェース仕様はシンプルで美しいのに
C言語インターフェースが邪悪なerrno変数を産んだ理由は何なの？

シグナル

>>573
おそらく誤解を含んでいると思われ、指摘しておくと
linuxのシステムコールであるopenやreadは、errnoは設定しない。
errnoを設定するのはC標準ライブラリ関数のfopen、freadだ。(errno自体もC標準ライブラリに属する変数だ。システムコールに属するものではない。)

ライブラリ関数はカスタムというか、OSには非依存、言語としての定義だね

>>580
Cの関数はシステムコールを生で提供していないニセモノだよな
errnoなどの独自カスタムをしている

本物になれなかった偽物と言うより意図して他層に作られた別物だよ
ファイル周りはハードウェア制御が関わる領域はOS側(システムコール)、バッファリング等のソフト寄りはユーザプログラム側(ライブラリ)で賄う構成が見て取れる。OSもプログラム言語も同時期に作ったからその塩梅は作り手の自在だったろうね

C言語はerrnoの存在やバッファオーバーフローを容易に発生させる関数も抱えたけど、当時の他言語が抽象化を進める代わりに実行効率を落とした。対してCは軽量なデザインによって高効率かつ充分高級な言語が実現できることを証明した。メモリ64KByte以下クロック10MHz未満のシステムでもコンパイルと実行、実用が可能だった
マルチスレッドや性善的設計に関わる問題まで初期開発当時に対処せよというならば、それは状況的に酷に思う

>>582
Rustはゼロコスト抽象化だから全てを手に入れたうえで速いよ
速いだけで全てがないCに勝ち目なし

Linux、UNIXはlibc使って、生のシステムコールを隠蔽してるんだよ
移植性のためだと思われ
OSによっては生システムコールのABI変更したりするそうだよ。appleとかappleとか

>>584
途中でlibcの実装を変えることはできないため
新たな環境な新たなアーキテクチャに対応する時に新たに決めるだけで後からの変更はできない
だからlibc使わずとも直接システムコール呼んで構わない

macOSでは生はダメだそうだ。
Linuxは御大のユーザーランドに迷惑をかけないという強い信念でABIが維持されているから大丈夫なだけだよ

組込みなら運用始まったら、カーネルとlibcを互換性崩れるようなものに入れ替えないのは、それはそう

何のスレかわからんが、ためになりました。linuxはともかく、winとかは大変みたいですね。

WindowsはWindowsで、Microsoftが血反吐を吐きながらWin32 API維持してくれてるから、たいへんという程でもないんじゃない？
Ansi版APIとUtf16版APIを意識しておく必要という点ではややたいへんとも言えるかもだが

最初期のRustコンパイラってRustで描かれてたの？
まさかC使ってたなんて言わないよね？

言わんね

>OCaml（旧称：Objective Caml）の最初のバージョン（1996年リリース）は、
>前身である Caml Special Light や Caml Light などをベースに開発されており、
>主に OCaml自身（およびCaml方言） および仮想マシン・ランタイム部分などに C言語 が使われて書かれました。
>なお、歴史をさらに遡った最初の「Caml」の処理系（1987年）は、Lisp で書かれていました。
フーンω

コンパイラもインタプリタも任意の言語で作れるからな
C言語なんて必要ない

最初だけは仕方ないわね。CコンパイラもアセンブリでCのサブセット言語作って、それで一旦コンパイルしてから、出来たやつでコンパルするとかややこしいことやってた

rust プログラムは、犯罪者AIの格好の標的

ターゲットは穴開きCとC++

腐れrustだよw

AIにC/C++のコードを吐かせるのはリスク高い

CUDAのRust実装とLLMの対応はよ

https://gihyo.jp/article/2026/09/cuda-rust
NVIDIAは2026年9月8日、GPU向け並列計算プラットフォームCUDAにおいてRustによる開発を可能にする「CUDA Rust」を発表した。
これまでCUDAにはC++あるいはPython用のプログラミングツールが用意されていたが、CUDA RustによりRustによるネイティブGPUプログラミングが可能となった。
GPUカーネルをRustで記述し、ネイティブにPTX（GPU用中間コード）にコンパイルできる。

周回おくれ