[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] misra: allow 'noreturn' as safe for function pointer conversions
On 29.07.2025 15:16, Nicola Vetrini wrote: > On 2025-07-29 15:09, Jan Beulich wrote: >> On 29.07.2025 15:02, Nicola Vetrini wrote: >>> On 2025-07-29 14:39, Jan Beulich wrote: >>>> On 29.07.2025 14:21, Dmytro Prokopchuk1 wrote: >>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl >>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl >>>>> @@ -367,6 +367,13 @@ constant expressions are required.\"" >>>>> } >>>>> -doc_end >>>>> >>>>> +-doc_begin="The conversion from 'void noreturn (*)(void *)' to >>>>> 'void >>>>> (*)(void *)' is safe >>>>> +because the semantics of the 'noreturn' attribute do not alter the >>>>> calling convention or behavior of the resulting code." >>>>> +-config=MC3A2.R11.1,casts+={safe, >>>>> + >>>>> "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1, >>>>> pointer(builtin(void)))))))&&from(expr(skip(!syntactic(), >>>>> + ref(property(noreturn)))))"} >>>>> +-doc_end >>>> >>>> As I understand it, this is about any function, not just void (void >>>> *) >>>> ones. >>>> Hence throughout anything textual in this patch, may I ask that this >>>> be >>>> made >>>> explicit by inserting e.g. "e.g." everywhere? >>> >>> Technically yes, in practice other implicit function pointer >>> conversions >>> would be caught by -Wincompatible-pointer-types and similar flags so >>> they don't even come into play. However I agree that adding that is >>> clearer. >> >> Perhaps a misunderstanding: With "any" I meant any which has a noreturn >> attribute, when converted to one with otherwise the same signature. But >> irrespective of the particular return type or parameter types (i.e. >> specifically not just void (void *) ones). > > Ah, sorry, I misunderstood. We check the destination type of the > conversion with > "to(type(pointer(inner(return(builtin(void))&&all_param(1, > pointer(builtin(void)))))))". In principle it could be avoided but I > think that at the moment it's ok as it is, then if it needs to be > extended when more cases emerge I can do that. Oh, then my comment to Dmytro (still in context above) was wrong. But why would we limit things as much? For noreturn functions a return type of other than void is surely not to be expected, so that part is fine. Yet any kinds of parameters would want to be permitted. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |