Summary
Canon-C's ownership annotations (owned(), borrowed(), moved(), dropped())
are documentation-level markers in C99, with DEFINE_OWNED(T) / DEFINE_BORROWED(T)
covering the type-distinction case at API boundaries (see docs/design-decisions.md,
OWN-001..003). For everything the C99 type system cannot express, the README
currently defers to external static analyzers.
This issue tracks evaluating that claim empirically: can Frama-C (and GCC's
-fanalyzer) actually perform the dataflow analysis needed to enforce the
lowercase annotations?
Properties to evaluate
For each tool, determine whether it can detect:
Candidate approaches
- Frama-C: mapping the lowercase annotations onto ACSL contracts
(e.g. \valid, allocates/frees clauses, ghost state for move status);
evaluate WP vs. EVA for which properties each can carry
- GCC
-fanalyzer: whether __attribute__((malloc)), ownership attributes,
or custom plugin work can encode drop/move semantics
- Optionally: whether the annotation macros should expand to tool-visible
markers under a CANON_ANALYSIS build flag instead of expanding to nothing
Deliverables
- A test corpus of small programs, one per violation class (use-after-move,
double-drop, stale borrow, aliased ownership), each in a "should flag" and
"should pass" variant
- A results matrix: tool × property → detected / not detected / detected-with-annotations
- Documented recipe in
docs/ for whichever combination works, or a recorded
negative result in docs/design-decisions.md if neither tool can carry a property
Status
Future work — not scheduled.
Summary
Canon-C's ownership annotations (
owned(),borrowed(),moved(),dropped())are documentation-level markers in C99, with
DEFINE_OWNED(T)/DEFINE_BORROWED(T)covering the type-distinction case at API boundaries (see
docs/design-decisions.md,OWN-001..003). For everything the C99 type system cannot express, the README
currently defers to external static analyzers.
This issue tracks evaluating that claim empirically: can Frama-C (and GCC's
-fanalyzer) actually perform the dataflow analysis needed to enforce thelowercase annotations?
Properties to evaluate
For each tool, determine whether it can detect:
moved()/ consuming parameterdropped()parameter twiceborrowed()valueoutliving the region/arena it was stamped with
owned()semanticswhen the pointer is copied, cast, or stored in a struct
Candidate approaches
(e.g.
\valid,allocates/freesclauses, ghost state for move status);evaluate WP vs. EVA for which properties each can carry
-fanalyzer: whether__attribute__((malloc)), ownership attributes,or custom plugin work can encode drop/move semantics
markers under a
CANON_ANALYSISbuild flag instead of expanding to nothingDeliverables
double-drop, stale borrow, aliased ownership), each in a "should flag" and
"should pass" variant
docs/for whichever combination works, or a recordednegative result in
docs/design-decisions.mdif neither tool can carry a propertyStatus
Future work — not scheduled.