Rustアンチスレ

>>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用中間コード）にコンパイルできる。

周回おくれ