Re: [Xen-devel] [PATCH v4 2/2] xen: use SYMBOL when required

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.01.19 at 19:29, <sstabellini@xxxxxxxxxx> wrote:
> On Mon, 7 Jan 2019, Jan Beulich wrote:
>> >>> On 04.01.19 at 18:05, <sstabellini@xxxxxxxxxx> wrote:
>> > I realize that you are not convinced by these arguments, but let's find
>> > a way forward. My preference would be to have SYMBOL returning unsigned
>> > long and do unsigned long comparisons when pointers pointing to
>> > different objects are involved.
>> 
>> I continue to fail to see how suitable hiding of the connection to the
>> original symbol from the compiler makes code less standard compliant
>> when comparing pointers: The compiler simply can't know whether
>> the underlying object is (in the extreme case) an array spanning the
>> entire address space.
> 
> That is because the requirement I am trying to address is MISRA-C
> compliance, which in turns requires C language compliance for C language
> (I think it allows mixing C with assembly code). I don't particularly
> care whether the compiler can or cannot find the connection to the
> original symbol. 
> 
> The important thing for me is to avoid comparisons (and subtractions)
> between pointers pointing to different objects. If we compare unsigned
> longs, it is easier to prove that the comparison is not between pointers
> pointing to different objects, even if somehow the numeric values
> indirectly come from pointers. If we compare pointers, even if they went
> through some sort of assembly conversions, we are still comparing
> pointers pointing to different objects. The compiler might not be able
> to figure it out, but a MISRA-C compliance scanning tool, or a human,
> might.

This is absurd: We are similarly still comparing pointers to different
objects when comparing their values casted to unsigned long. The
cast is as much of a hiding technique as any other one. If you want
to be C language compliant without any compromises, you'll have to
do away with all *_end symbols. You may recall that I did propose
a patch doing so (for an entirely different reason), using the tool
chain's .sizeof.() operator (and then for consistency also its
.startof.() counterpart).

Jan



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