RTEMS | libdebugger/rtems-debugger-*.c: Address ignored qualifier warnings (!803)

[Joel Sherrill (@joel)]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20251017/fc0f4dc8/attachment.htm>