Joel Sherrill commented on a discussion on 
cpukit/libdebugger/rtems-debugger-aarch64.c: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/803#note_135136

 >    memcpy( &thread->registers[ offset ], &value, sizeof( uint64_t ) );
 >  }
 >  
 > -static const uint64_t rtems_debugger_get_int_reg(
 > +static uint64_t rtems_debugger_get_int_reg(

@chris I got a reply quickly from the folks at LDRA with an augmented version 
of the example I sent.

The quick answer is that this warning catches the presence of meaningless 
quallfiers which besides removing syntactic cruft is a MISRA violation

> The warning is because the const is meaningless.  Ok, now that is out of my 
> system.   
>
> It's meaningless because the function return cannot enforce the const-ness of 
> the return values storage. The retval only exists as a temp copy. If you 
> don't check a return, the value just exists and dies.  it's extra chatter in 
> our code. Which if it was not a MISRA violation, it is certainly against the 
> spirit of the guidelines which to me say "be explicitly clear on everything 
> and do not use conventions that obfuscate the truth."  
>
> The applicable rule is: 
>
> Rule 17.13 A function type shall not be type qualified (Required) 
>
> The type qualifiers are const, volatile, restrict or \_Atomic  
>
>  These are my notes. Left it if you find it interesting:  I think this is an 
> lvalue, rvalue issue.  Lvalue has persistent storage. Is the stuff on the 
> Left side of =. Rvalue is a temporary value and doesn't have to exist later, 
> Is the stuff on the right side of the =.  A function cannot be an Lvalue. The 
> const is immaterial because there is no persistent storage. We return to the 
> caller and it is responsible for doing something with that return value. 

The example code he provided back to show more on this is 
[ignored-qualifiers2.c](/uploads/1a24243027e91a197d8a1c0146bdfc7b/ignored-qualifiers2.c)

I would recommend you approve this MR and resolve the comment with an issue for 
rtems-docs to add this to our Coding Guidelines with some rationale.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/803#note_135136
You're receiving this email because of your account on gitlab.rtems.org.


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to