On 04/02/2019 20:08, Stefano Stabellini wrote: > On Mon, 4 Feb 2019, Jan Beulich wrote: >>>>> On 01.02.19 at 19:52, <dunl...@umich.edu> 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.
I can make a decision whether the series is fine for 4.12, but for being ready to be committed I can only have an opinion or make a suggestion. In my opinion we should try to move forward. Fighting opinions of compiler developers won't help as George pointed out in a slightly sarcastic way. ;-) While a completely future proof solution would be nice I don't think this is achievable now. And we should be aware that a solution being better than what we have today should be preferred over a perfect solution which doesn't work due to compiler issues. >> 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? This would be my suggestion, too. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
