[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, 4 Feb 2019, Jan Beulich wrote:
> >>> On 01.02.19 at 19:52, <dunlapg@xxxxxxxxx> wrote:
> 
> I'm not going to reply in detail to all of what you wrote about fanatics,
> but I would like to say that I think compiler people less of that than
> you appear to imply, at least the ones I know. In particular, they can
> be convinced of there being bugs by pointing out what aspect of the
> standard their implementation violates. (Of course there are also
> going to be areas where interpretations of the standard vary too
> much to come to an agreement.)
> 
> > Improvements this series seeks to make, as I understand it, include
> > (in order of urgency):
> > 
> > 1. Fixing one concrete instance of "UB hazard"
> 
> Right, and we want to work around compiler bugs here.
> 
> > 2. Minimize risk of further "UB hazard" in this bit of functionality
> > 3. Retain the effort Stefano has put in identifying all the places
> > where such UB hazards need to be addressed.
> > 4. Move towards MISRA-C compliance.
> > 
> > As far as I can tell, primary objections you've leveled at the options
> > which try to address 2-4 are:
> > 
> > a. "UB hazard" still not zero
> > b. MISRA compliancy no 100%
> > c. Ugly
> > d. Inefficient
> > 
> > (Obviously some proposals have had more technical discussion.)
> > 
> > Anything I missed?
> 
> I don't think so, especially since various aspects can fall under "ugly"
> and/or "inefficient". What I'm not sure I see is what you mean to
> express with all you wrote in terms of finding a way out of the
> current situation (besides requesting a vote): Improving on a. and
> b. is not a good excuse to extend c., at least not unequivocally.
> Whether d. actually matters is a separate aspect, partly because it
> may mean different things (it could e.g. be taken as another
> wording for a. and b.).

I would be OK with a vote (or Juergen making a decision for us), but
this issue is not so fundamentally critical that I want to move forward
with it at the cost of making one or more maintainers unhappy. Ideally,
I would like to find an option that is acceptable for everybody.
Unfortunately, it doesn't look like it's possible.


> And btw - I can't judge on b. anyway, as I still don't know what
> exactly MISRA compliance is to mean, with the rules to adhere to
> suitably justified.

I can't pretend to know exactly what MISRAC compliance means for this
specific issue, but we do have the recommended way forward by the
compliance experts, which also matches the rough understanding of most
of the engineers involved in this discussion. Picking the option
suggested by the MISRAC people, could be a decent way to settle this
debate?

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.