On 05/03/2019 22:38, Stefano Stabellini wrote: > Hi all, > > This version of the series makes use of the macro suggested by Jan with > few modifications. See each patch for a description of the changes. > > The following changes since commit 808cff4c2af66afd61973451aeb7e708732abf90: > > sched/credit2: remove stale comment (2019-01-09 15:46:05 +0100) > > are available in the git repository at: > > http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git > certifications-11 > > for you to fetch changes up to 26fb02b5ae59b48b51ca788be91510d8df48ab0a: > > xen: explicit casts when DECLARE_BOUNDS cannot be used (2019-03-05 14:29:51 > -0800) > > ---------------------------------------------------------------- > Stefano Stabellini (9): > xen: use __UINTPTR_TYPE__ for uintptr_t > xen: introduce ptrdiff_t > xen: introduce DECLARE_BOUNDS > xen/arm: use DECLARE_BOUNDS as required > xen/x86: use DECLARE_BOUNDS as required > xen/common: use DECLARE_BOUNDS as required > xen: use DECLARE_BOUNDS as required > xen: use DECLARE_BOUNDS in alternative.c > xen: explicit casts when DECLARE_BOUNDS cannot be used
Seriously. Everyone take a step back from their keyboards and apply some common sense. This argument has gone on far beyond the only answer which matters. WTF is still continuing for? (This is a rhetorical question - I don't expect an answer.) The rational for this series is to satisfy MISRA. MISRA have said in no uncertain terms that all of these tricks are unacceptable, and have identified the one acceptable option. By not doing what MISRA said, this series doesn't move Xen any closer to passing certification. Therefore, we either do nothing, or we do the single thing which MISRA have identified as acceptable. Obviously, "do nothing" is off the cards in the context of this series. Before any further arguing continues (especially concerning the details of how to proceed), are there any concerns or queries with the points laid out here? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel