Re: [Xen-devel] SRSL People... [PATCH v11 0/9] misc safety certification fixes

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.03.19 at 16:26, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

Iirc they said to use casts in a central place. Am I misremembering?
Because that's what the series does.

Jan



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