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

Joel Sherrill (@joel) gitlab at rtems.org
Fri Oct 17 14:34:48 UTC 2025




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

 >    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(

Starting with the GCC documentation on the -Wignored-qualifiers option, specifying const on a function that returns a scalar type is meaningless. In C, it is enforced as an attribute of returned pointers.

> '-Wignored-qualifiers (C and C++ only)'
>      Warn if the return type of a function has a type qualifier such as
>      'const'.  For ISO C such a type qualifier has no effect, since the
>      value returned by a function is not an lvalue.  For C++, the
>      warning is only emitted for scalar types or 'void'.  ISO C
>      prohibits qualified 'void' return types on function definitions, so
>      such return types always receive a warning even without this
>      option.
> 
>      This warning is also enabled by '-Wextra'.

I found a [Stack Overflow discussion](https://stackoverflow.com/questions/1134237/pedantic-gcc-warning-type-qualifiers-on-function-return-type) on this but it does not seem to add much. Someone noted that having the const on the function return value and it being meaningless could result in a programmer thinking there is some guarantee being checked on the function where there simply is none. I found this statement at [EEVBlog Electronics](https://www.eevblog.com/forum/programming/c-functions-with-volatile-return-types-what-does-it-mean/) which aligns with "you can type it, but it is meaningless".

> In C language it means absolutely nothing. In C the return value is an rvalue and C does not support cv-qualification of rvalues. Meaning that you can legally apply such qualification in the source code, but it will be ignored anyway.
> 
> It is all natural aside from one corner case, which exists since C99: when the returned object is a struct with an array inside.

This reminds me of a line from _The Princess Bride_ where Inigo Montoya says "You keep saying that word. I do not think it means what you think it means." 

I have asked a contact at one of the companies that makes a static analyzer that includes checking against various coding standards including MISRA. Hopefully they can add some more to the rationale.

Beyond that, this warning only flagged these cases. How do you think this comment should be resolved? 

1. One option add this information to the Coding Guidelines in the Software Engineering Guide. 
2. Another is to consider this discussion sufficient.
3. Disable this warning even though this pattern is rare in the code base. This MR addresses all cases.

What's your preference? It is involves documentation, resolve with an issue in rtems-docs to address this.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/803#note_135132
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/0669eecb/attachment-0001.htm>


More information about the bugs mailing list