Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.01.19 at 19:46, <Stewart.Hildebrand@xxxxxxxxxxxxxxx> wrote:
> On Thursday, January 10, 2019 12:30 PM, Stefano Stabellini wrote:
>> On Thu, 10 Jan 2019, Jan Beulich wrote:
>> > >>> On 10.01.19 at 03:40, <julien.grall@xxxxxxxxx> wrote:
>> > > On Wed, 9 Jan 2019, 18:43 Stefano Stabellini, <sstabellini@xxxxxxxxxx>
>> > > wrote:
>> > >
>> > >> Introduce a macro, SYMBOL, which is similar to RELOC_HIDE, but it is
>> > >> meant to be used everywhere symbols such as _stext and _etext are used
>> > >> in the code. It can take an array type as a parameter, and it returns
>> > >> the same type.
>> > >>
>> > >> SYMBOL is needed when accessing symbols such as _stext and _etext
>> > >> because the C standard forbids for both comparisons and substraction
>> > >> (see C Standard, 6.5.6 [ISO/IEC 9899:2011] and [1]) between pointers
>> > >> pointing to different objects. _stext, _etext, etc. are all pointers to
>> > >> different objects from ANCI C point of view.
>> > >>
>> > >
>> > > This does not make sense because you still return a pointer and therefore
>> > > the undefined behavior is still present.
>> > >
>> > > I really don't believe this patch is going to make the MISRA tool happy.
>> >
>> > Well, till now I've been assuming that no version of this series was
>> > posted without being certain the changes achieve the goal (of
>> > making that tool happy).
>> 
>> No, Jan: unfortunately we cannot re-run the scanning tool against any
>> version of Xen we wish to :-(
>> 
>> We cannot know in advance if a set of changes will make the tool happy
>> or not.
> 
> Playing devil's advocate: even with all sorts of casting and inline assembly
> to suppress static analysis tool warnings, we're still not addressing the
> underlying rule violation. A pointer value casted or fed through some inline
> assembly at the end of the day is still a value that represents an address
> in an object. And as soon as we subtract or compare that value to one
> that represents another object we start violating the MISRA rules (this is
> my own rather strict interpretation for the purpose of making a point - 
> please feel free to disagree). 

I agree, but I don't see how to solve this. Linker generate symbols
are - like all symbols originating outside of C files - not necessarily
following the C spec anyway. Here, the *_end labels really don't
mark any objects.

> If all we really care about is making PRQA happy, I believe it does support
> some sort of comment-based suppression. I've seen comments like
> /* PRQA S 0487 */ or /* PRQA S 0488 */ in various codebases, I'm guessing
> comments like this have something to do with suppressing these types of
> warnings.

I have to admit that I'm opposed to comments: We've got some
to please Coverity. We've got others to make certain editors to
work for certain people. How many more are we going to gain?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel