[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 9/9] xen: add SAF deviation for safe cast removal.
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |