Reduce unsafe code in SQLite

Aperta
  • Qualcosa non va?
#4,096 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
22/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
rust, sqlite
Ambito
databases

Direzione di ricerca

This is a project-wide audit of unsafe in the SQLite backend, not a single-file edit. Search sqlite-related modules for unsafe blocks, shrink each to the individual FFI calls, and add SAFETY comments for the invariants. Mark helpers unsafe when they cannot check those invariants and document them for callers. No files or tests are named; start from the crate’s SQLite sources. Done means tighter blocks plus comments, possibly some public APIs marked unsafe. The issue is 330 days old with no comments, so check with maintainers before a large PR.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement
I have found these related issues/pull requests

No related issues.

Description

SQLx advertises not using any unsafe code, except for SQLite. This is great, however where unsafe code is used, it often wraps the whole function, not just the individual function calls that require the unsafe block. This makes it harder to see where SAFETY comments are needed.

There's about 100 unsafe blocks at the moment, many of which contain multiple unsafe calls, and there are only 36 SAFETY comments.

For a project that advertises itself on not using unsafe code where it doesn't need to, this is surprising.

I also suspect there are cases of functions that assume invariants in their parameters that go unchecked, and as such should be marked as unsafe, but haven't been.

Prefered solution

Put unsafe blocks only around individual unsafe function calls.
Add SAFETY comments to function calls detailing the invariants the function expects, and why they are met.
If the function cannot guarantee that they are met it should be marked as unsafe, have it's invariants documented, and have SAFETY comments added to the callers explaining how they uphold the invariants.

I don't have time to do this myself at the moment, and I know you don't have the time either, so this probably isn't getting done any time soon. But I still think it's a problem that deserves an issue.

Is this a breaking change? Why or why not?

There may be some public APIs that have to be made unsafe, but most of the code this effects is internal

Lingua principale
Rust
Stelle
17.5k
Fork
1.7k
Merge medio
1g 17h
PR unite (30g)
7

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di transact-rs/sqlx

Tutte le issue di transact-rs/sqlx

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.