I thought meaningless was sufficient but others in the discussion felt it had value and wanted more. But the return value is scalar so it is const implicitly. You can't modify it. Only assign or compare.
I did ask someone from a company with a static analyzer and there is a MISRA rule "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" Now I have more to defend the warning with. Thanks. On Fri, Oct 17, 2025, 10:36 AM Jason Merrill <[email protected]> wrote: > Is there a reason not to remove the meaningless qualifiers? Generally the > rationale for warning about something that has no effect is that presumably > when you wrote it you expected it to do something. > > On Fri, Oct 17, 2025 at 5:50 PM Joel Sherrill <[email protected]> wrote: > >> Hi >> >> I have been trying to eliminate all warnings at -Wextra for RTEMS before >> we >> make our next major release. There were a handful of cases where >> -Wignored-qualifiers. I understand it is meaningless to have qualifiers on >> scalar return values, but I was hoping someone here might have more to add >> for rationale than "has no effect". >> >> Is there any coding standard (MISRA, JPL, etc.) where this is explicitly >> forbidden? Or mentioned? >> >> -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. >> >> I have attached a simple C function which generates the warning if that >> helps anyone. >> >> Thanks. >> >> --Joel Sherrill >> RTEMS >> >
