Rustアンチスレ

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

周回おくれ