rjmccall wrote: The suggestion was specifically limited to parameters: basically, when expressions are used to initialize parameters, the final conversion to the parameter type should work as if the parameter did not have an OBT.
`__ob_trap` as currently designed really only provides strong safety properties downstream of the annotation. If you want to ensure that a value was produced correctly, you need the whole computation tree to be `__ob_trap`. If the argument expression is `__ob_trap`, you get that, at least within a slice of the expression tree; but if the argument expression is not `__ob_trap`, checking for overflow only in the final conversion to the parameter type is not likely to provide meaningful mitigation. Meanwhile, there are very significant incremental-adoption benefits for annotations having purely local impact. Being able to add `__ob_trap` to a local variable and be sure that it's only going to change behavior within the function is a big deal, and that applies to parameters just as much as anything else. So in a sense, the suggestion is to make `__ob_trap` only apply locally rather than having this low-value effect on callers that would interfere with incremental adoption of `__ob_trap`. We'd also talked about some kind of parameter attribute that would add overflow checking to the argument expression. That is, of course, inherently non-local, and therefore has unavoidable incremental-adoption problems. It also has a serious safety problem in that it doesn't recursively apply: it would add checking to ```c void *ptr = malloc(n * sizeof(widget_entry_t)); ``` but not to ```c size_t alloc_size = n * sizeof(widget_entry_t); void *ptr = malloc(alloc_size); ``` An alternative design would be to add a warning for all implicit conversions of non-constant values to `__ob_trap` types. This, of course, goes back to having serious incremental-adoption issues, but you could work through them incrementally with a diagnostic pragma. For example, you could turn the warning on globally in your local build, fix a few files, add pragmas to enable the warning in those files, and then undo the global change when you go to commit. This warning would still want to consider parameters declared with `__ob_trap` type to be `__ob_trap`, of course. A warning like this would, in a way, end up enforcing the same properties I know you're looking at strong typedefs for, but without even more changes to the basic mechanics of C. (Of course, it wouldn't work for e.g. providing type-safe dimensions! But I think you'll find more resistance to that than you might expect.) There was a secondary discussion about whether OBTs should be part of the signature of the function for the purposes of overloading, mangling, and so on, and I think the consensus there was "definitely not". Again, you want adopting `__ob_trap` on a parameter to not be an ABI-breaking change. https://github.com/llvm/llvm-project/pull/148914 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
