On Sat, Nov 13, 2021 at 9:37 PM David Malcolm <dmalc...@redhat.com> wrote: > > #define __user __attribute__((untrusted)) > > where my patched GCC treats > T * > vs > T __attribute__((untrusted)) * > as being different types and thus the C frontend can complain (even without > -fanalyzer) about e.g.:
This one sounds similar to the `Untrusted<T>` wrapper I suggested for the Rust side -- we would have a method to "extract and trust" the value (instead of a cast). > Patch 2 in the kit adds: > __attribute__((returns_zero_on_success)) > and > __attribute__((returns_nonzero_on_success)) > as hints to the analyzer that it's worth bifurcating the analysis of > such functions (to explore failure vs success, and thus to better > explore error-handling paths). It's also a hint to the human reader of > the source code. These two sound quite nice to have for most C projects. Would it be useful to generalize to different values than 0/non-0? e.g. `returns_on_success(0)` and `returns_on_failure(0)`. Cheers, Miguel
