On 7/31/25 10:20, Jan Beulich wrote: > On 30.07.2025 23:47, Dmytro Prokopchuk1 wrote: >> --- a/docs/misra/deviations.rst >> +++ b/docs/misra/deviations.rst >> @@ -342,6 +342,12 @@ Deviations related to MISRA C:2012 Rules: >> semantics that do not lead to unexpected behaviour. >> - Tagged as `safe` for ECLAIR. >> >> + * - R11.1 >> + - 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. >> + - Tagged as `safe` for ECLAIR. > > As before, imo such a deviation should be generic, i.e. here independent > of what parameters a function takes. If that can't be easily expressed > to Eclair, then that wants stating as a justification for the > deviations.ecl change to not fully cover the deviation we put in place. > Having the textual deviation generic means later possible needs can be > easily addressed by just a deviations.ecl change, without any adjustment > to the deviations themselves. > > Jan
Hi, Jan Currently Eclair checks exact pointer type 'void (*)(void *)', as described in the configuration: to(type(pointer(inner(return(builtin(void))&&all_param(1, pointer(builtin(void))))))) Nicola wrote: "then if it needs to be extended when more cases emerge I can do that". So, for clarification. 1. In the file "deviations.ecl" I leave exist description and config: "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." 2. In the file "deviations.rst" I change the description to: "The conversion from `void noreturn (*)(...)` to `void (*)(...)` is safe because the semantics of the 'noreturn' attribute do not alter the calling convention or behavior of the resulting code, parameter handling remain consistent." 3. In the file "rules.rst" I change the description to: "Conversions from 'void noreturn (*)(...)' to 'void (*)(...)' are permitted." It means that only "deviations.ecl" needs to be updated if a new deviation needs to be addressed. Is it OK? Dmytro
