Re: [PATCH 9/9] xen: add SAF deviation for safe cast removal.

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 18 Dec 2023, Jan Beulich wrote:
> On 15.12.2023 22:02, Stefano Stabellini wrote:
> > On Fri, 15 Dec 2023, Jan Beulich wrote:
> >> On 14.12.2023 23:04, Stefano Stabellini wrote:
> >>> On Thu, 14 Dec 2023, Jan Beulich wrote:
> >>>> On 14.12.2023 13:07, Simone Ballarin wrote:
> >>>>> --- a/docs/misra/safe.json
> >>>>> +++ b/docs/misra/safe.json
> >>>>> @@ -28,6 +28,14 @@
> >>>>>          },
> >>>>>          {
> >>>>>              "id": "SAF-3-safe",
> >>>>> +            "analyser": {
> >>>>> +                "eclair": "MC3R1.R11.8"
> >>>>> +            },
> >>>>> +            "name": "MC3R1.R11.8: removal of const qualifier to comply 
> >>>>> with function signature",
> >>>>> +            "text": "It is safe to cast away const qualifiers to 
> >>>>> comply with function signature if the function does not modify the 
> >>>>> pointee."
> >>>>
> >>>> I'm not happy with this description, as it invites for all sorts of 
> >>>> abuse.
> >>>> Yet I'm also puzzled that ...
> >>>
> >>> We can improve the language but the concept would still be the same. For
> >>> instance:
> >>>
> >>> A single function might or might not modify the pointee depending on
> >>> other function parameters (for instance a single function that could
> >>> either read or write depending on how it is called). It is safe to cast
> >>> away const qualifiers when passing a parameter to a function of this
> >>> type when the other parameters are triggering a read-only operation.
> >>
> >> Right, but I think the next here needs to be setting as tight boundaries
> >> as possible: It should cover only this one specific pattern. Anything
> >> else would better get its own deviation, imo.
> > 
> > OK. What about:
> > 
> > A single function might or might not modify the pointee depending on
> > other function parameters, for instance a common pattern is to implement
> > one function that could either read or write depending on how it is
> > called. It is safe to cast away const qualifiers when passing a
> > parameter to a function following this pattern when the other parameters
> > are triggering a read-only operation.
> > 
> > Feel free to suggest a better wording.
> 
> Well, my point was to get rid of "for instance" and "common pattern" (and
> anything alike). E.g.:
> 
> "A single function could either read or write through a passed in pointer,
>  depending on how it is called. It is deemed safe to cast away a const
>  qualifier when passing a pointer to such a function, when the other
>  parameters guarantee read-only operation."

That's fine by me