Rustアンチスレ

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

周回おくれ