tptacekのコメントが気になるな（https://news.ycombinator.com/item?id=28279426）。「このページの「セキュリティ」に関する段落は、他の議論を損なっている。実際、CはSQLiteにとって明らかなセキュリティリスクだ。」現在のドキュメントにはセキュリティに関する段落も「セキュリティ」という言葉すら一度もない。2021年版のドキュメントには、今はもう見当たらないこの文が含まれていた：「安全な言語は、セキュリティの脆弱性を防ぐのに役立つとしばしば謳われる。確かにそうだけど、SQLiteは特にセキュリティに敏感なライブラリではない。アプリケーションが信頼できないSQLを実行しているなら、すでにもっと大きなセキュリティ問題（SQLインジェクション）があるし、どんな「安全な」言語でもそれを解決することはできない。アプリケーションが信頼できないソースから完全なバイナリSQLiteデータベースファイルをインポートすることがあるのは事実だけど、そのようなインポートは攻撃ベクトルになる可能性がある。しかし、SQLiteのそのコードパスは限られていて、非常によくテストされている。そして、信頼できないデータベースを読み取ることを望むアプリケーションには、使用前に可能な攻撃を検出するのに役立つ事前検証ルーチンが用意されている。」 https://web.archive.org/web/20210825025834/https%3A//www.sql...

その分岐は、範囲外に出ることが証明されていないから、そもそも存在しないことが多いと思います。コンパイラが範囲を破ることができないことを知っていることを確実にする方法があります。

この問題は、無条件でパニックに至る分岐のカバレッジを要求しないことで軽減できるのかな？それとも、正しいコードでは決して発生しないことを示すマークをその分岐に付けることができるのかな？

つまり、安全な言語が生成するのは、例えばこういうこと？ // 疑似コード if (i >= array_length) panic("インデックスが範囲外") 実際にコードが正しければ、これは決して実行されない？でも（私が正しく理解していれば）これはコンパイラによって暗黙的に追加されたチェックだよね。だから、異議はこの自動生成されたコードの正しさを疑うことに帰着するし、コンパイラの正しさを信頼していないことが前提になってる？でも、Rustコンパイラ自体はこれらのチェックが機能することを徹底的にテストしているはずだよね？もし私が議論を誤解していたら、誰か訂正してほしいな。

これは、ほとんどの人やプロジェクトからは受け入れられないような議論だけど、ヒップ博士からのは別だし、SQLiteも普通のプロジェクトじゃないからね。

安全だとわかっているなら、get_unchecked()みたいなメソッドを使って境界チェックを避けられない？

その議論にはあまり説得力を感じないな。もしコードのブランチが絶対に取られないと確信しているなら、それをテストする必要もないと自信を持つべきだと思う。これは安全性を犠牲にして無理に100%のテストカバレッジを追い求めているように感じる。チェックを省いたからといってコードの質が向上するわけじゃないし、テストカバレッジが上がるだけなんだよね。

考えるのは面白いけど（ページ全体がよく考えられてるね）、その主張は検証に耐えないと思う。自動的な境界チェックが失敗したら、プログラムはその分岐なしで未定義の動作を示してしまうし、未定義の動作（UB）は、何かしらの明確な処理をする到達不能な分岐よりも厄介だよね。Cでのシンプルな配列アクセス：arr[i] = 123; は、こう考えられるかも：if (i >= array_length) UB(); else arr[i] = 123; ここで「UB」関数は何でもできるからね。ソフトウェアの徹底的なテストと形式的な検証の観点からは、安全な言語の同等のものが欲しいな：if (i >= array_length) panic(); else arr[i] = 123; ...だって、少なくとも到達不能な条件が発生した場合に何が起こるか考えられるから。ヒップ博士は「SQLiteをGoで再コーディングするのは難しい、なぜならGoはassert()が嫌いだから」と言ってるけど、これはSQLiteが到達不能な条件を守るためにassert文を使っていることを示唆してるよね。彼のテストインフラは、到達不能なassert分岐を免除する方法があるはずなのに、なぜ境界チェック（未定義の動作が発生しないことを確認するだけのもの）が同じように扱えないんだろう？

「間違ったコードでは分岐が発生するけど、分岐のないコードは予測できない動作をするだけなんだ。シートベルトみたいなもんだよ。例えば、4ブロック運転してからシートベルトが必要になるケースがあったらどうする？まあ、そのための明確なテストはあるけど、全てをテストすることはできない。4ブロック運転して右折して、半ブロック後に何かにぶつかる場合をテストしてないし。もういいや、シートベルトを外して、シートベルトがちゃんと機能するかどうか不確実なこの狂った未テストの領域をなくそう！」

新しい理由は、全く意味がないからだよ。Cでは、配列アクセスごとに暗黙の「ブランチ」があるんだ。それはアクセス違反と呼ばれている。コードベースのすべての配列アクセスでセグフォルトをテストしてるの？してない？じゃあ、実際には100%のブランチカバレッジはないってことだね。

1. Rustは1.0から10年が経過しました。後方互換性のある形で変化しています。ある人たちは全く変化を望まないので、どの意味で言っているのかを明確にすることが重要です。
2. これは実証されています。
3. これは「マイナー」の定義によりますが、「オペレーティングシステムなし」の部分は明確に実証されています。
4. 私は専門家ではありませんが、バイナリをテストしているので、Rust特有のものが何かは分かりません。Ferroceneの人たちがこの作業をいくつか行ったことは知っていますが、現在の状況は分かりません。
5. Rust自体はメモリの割り当てを行いません。このOOMの挙動は標準ライブラリによるもので、これらの組み込みケースでは使用していません。そこでは、すべてライブラリコードなので、好きなようにできます。
6. これも多くの定義に依存するので、どちらとも言えるかもしれません。

Goで`if condition { panic(err) }'をアサートの代わりに使えないのはなんで？

そして変更の頻度は低い（またはゼロ） これは、去年Googleのセキュリティブログが言っていたことと一致するね。「[メモリ安全性]の問題は新しいコードに圧倒的に多い...コードは成熟して時間と共に安全になる。」

もうGoにSQLiteのポートがあるよ :) https://gitlab.com/cznic/sqlite

「SQLiteはGoやRustで再コーディングできるけど、そうすると修正されるバグよりも新たにバグが増える可能性が高いし、コードが遅くなるかもしれない。」どうなるか見てみよう。Rust側にはかなり活発なTursoがあるよ。 https://turso.tech/

これありがとう、完全に同意するよ。最近の傾向でイライラするのは、5年以上前のものを軽蔑して、全く関係ない、時代遅れだと見ることだね。年を取っただけかもしれないけど、技術は信頼できて退屈なものが好きなんだ、特にソフトウェアは。私たちが当たり前に思っていることに何十年もの専門知識が注がれていることを尊重する人がいるのを見るのは嬉しいよ。

一つの良い理由は、ゴーランのアダプターが書かれているから、cgoなしでsqliteデータベースを使えるってことだね。あなたが言ってることには同意するよ。「sqlite」はある程度普及していて、単一の実装を超えて進化しているんだ。もちろん、Cライブラリのsqliteもあるけど、sqliteのデータベースファイルフォーマットもあって、ゴーランでsqliteの実装があっても全然おかしくない（実際、すでにあるし）し、純粋なRustの実装もできると思う。将来的には純粋なRustの実装も出てくるだろうし、もっと遠い未来にはそれが主流の実装になるかもしれないね。

実際、そういう実装は存在するよ。少なくともRustにはrqliteとtursoがあるしね。

でも、なんで完璧なCの実装を捨てる必要があるの？それに、25年間SQLiteを丁寧にメンテナンスしてきたCの専門家たちが、新しい言語を学んで最初からやり直すことを期待するの？言語の提唱が、他の人に自分のやりたいことを押し付けるだけになってしまっているからだよ。言語の採用はゼロサムゲームみたいなもので、プロジェクト'x'を言語'y'で開発しているなら、定義上言語'z'では開発していないことになる。これが言語'z'の地位を下げて、プロジェクト'x'が言語'z'で書かれていなくても続いていると、言語'z'が本当に必要なのか疑問に思わせるんだ。しかも、もし'x'の著者がどの言語で書くかを再検討したら、言語'z'だけじゃなくて、言語'd'、'l'、'j'、'g'も候補に上がるだろうね。

タイトルが編集されているから。

確かに。SQLiteがCで書かれていて、BASICじゃないのはなんでだろう？

ちなみに、そんなプロジェクトがあるよ：https://github.com/tursodatabase/turso 彼らのブログには「なぜ」の答えがヒントとして書かれてる：https://turso.tech/blog/introducing-limbo-a-complete-rewrite...

Rustのメモリ安全性の保証は、ヒープ割り当てに限定されないよ。実際、言語自体はヒープ割り当てを全くしない。希望があれば、Cと同じようにリンクリストを書くこともできる。

それに、ダブルリンクリストやグラフは使ってるの？それらは、Rustが自分で仮想ポインタのアリーナを作らせるから、Cではある意味安全かもしれない。Rustでも生ポインタといくつかのunsafeコードを使えば、Cと同じようにリンクリストを実装できるよ。実際、標準ライブラリにもそれがあるし。

「SQLiteは本番リリースでメモリリークや削除後の使用バグがあったことがあるの？もちろん、古いライブラリだから、ほとんど何でもあるよ（彼らが何をしているかわからないからじゃなくて、いろいろ起こるから）。最近のCVEを見てみよう：- CVE-2025-29088 タイプ混乱 - CVE-2025-29087 範囲外書き込み - CVE-2025-7458 整数オーバーフロー、最適化されたRustでは可能だけど、テストビルドではチェックされてる - CVE-2025-6965 メモリ破損、Rustが助けにならなかったかも - CVE-2025-3277 整数オーバーフロー、Rustが助けになったかも - CVE-2024-0232 使用後解放 - CVE-2023-36191 セグメンテーション違反、Rustが助けになったか不明 - CVE-2023-7104 バッファオーバーフロー - CVE-2022-46908 検証ロジックエラー - CVE-2022-35737 配列境界オーバーフロー - CVE-2021-45346 メモリリーク... 見ての通り、sqliteのCVEの大半はRustでは起こりにくい（でも、Rustのsqlite実装はunsafeを使う可能性が高いから、全く不可能ではない）。ちなみに、2025年にこんなに多くのCVEがあるのは、Googleみたいな会社がSQLiteのファズテストをかなりやっているからかもしれない。他のポイントとしては、- 100%の分岐カバレッジは素晴らしいけど、Cではメモリの健全性を保証しない - SQLiteのCVEを深く探る人がいるおかげで、見た目ほど悪くない。最後に一つ質問：SQLiteは最高のCプログラマーを使っているけど、彼らがコードにマージするのは限られた変更だけで、典型的な会社プロジェクトに比べて変更の度合いは非常に少ない。それでもメモリの脆弱性がある。新しいプロジェクトにCを使う理由は何なんだ？」

あなたの提案する主張は、古いコードベースのメンテナンスモードを正当化するためだけに機能する。新しい開発者をC++やRustみたいな複雑なものや、Javaのようなガーベジコレクションの遅い言語から引き離して、Cという比較的シンプルで普及している言語を考えさせたいなら、もっと何かを提供しないと。

（2017年のものだよ）

「でも、彼らが挙げる他の主張は細かく分析できて、半分は真実に過ぎない」他の主張を分析するのを見てみたいな。