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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.01.19 at 00:41, <sstabellini@kernel.org> wrote:
> We haven't managed to reach consensus on this topic. Your view might be
> correct, but it is not necessarily supported by compilers' behavior,
> which depends on the opinion of compilers engineers on the topic, and
> MISRAC compliance, which depends on the opinion of MISRAC specialists on
> the topic. If we take your suggested approach we end up with the code
> most likely to break in case the compilers engineers or the MISRAC
> experts disagree with you. In this case, being right doesn't necessarily
> lead to the code less likely to break.
> 
> Regardless, if that is the decision of the Xen community as a whole,
> I'll follow it. My preference remains with approach 3. (var.S), followed
> by approach 2. (SYMBOL_HIDE returns uintptr_t), but I am willing to
> refresh my series to do approach 1. (SYMBOL_HIDE returns pointer type)
> if that is the only way forward.
> 
> Let us come to a conclusion so that we can move on.

How can we come to a conclusion when things remain unclear? I see
only two ways forward - either we settle the dispute (which I'm
afraid would require involvement of someone accepted by all of us
as a "C language lawyer", which would include judgment about the
MISRA-C implications), or you request a vote, by which my
objection to _any_ change here without proper justification can be
outvoted. Only at that point can we then decide whether any of
the proposed "solutions" (in quotes because I remain unconvinced
there's a problem to solve here other than working around compiler
bugs) is/are necessary _and_ fulfilling the purpose, and if multiple
remain, which of them we like best / is the least bad one.

Jan



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