Reduce const-related warnings

[mwoehlke-kitware]

Description

Don't remove const-ness where there is no need to do so, and use const_cast when it is necessary (particularly in qgui). Refactor plotting to accept immutable data, and refactor some data marshaling to pass immutable points rather than mutable points to avoid unnecessary adaptation.

This significantly reduces -Wcast-qual warnings. Also turn that on by default to reduce the chances of regressions.

(Individual commits may have more details.)

Which blocks/areas does this affect?

This should have negligible to no impact on code generation, since not dropping const when not needed should have no effect, and replacing C-style casts with const_cast definitely should have no effect. I don't expect changing vector<double*> to vector<const double*> to have any effect either, as the vector still holds a mutable pointer in both cases. (Note that we're talking about mutable pointers to (im)mutable data; that is, the pointers are always mutable, the change is whether what they point to is const. I can readily imagine vector<T> and vector<T const> having different codegen, but I don't know any reason why vector<T*> and vector<T const*> would differ.) The usage never needed mutable data, so should not be affected.

Testing Done

Compiled locally with -Werror=cast-qual on Fedora 39 and ran ctest.

Checklist

• I have read the CONTRIBUTING document.
• I have squashed my commits to have one significant change per commit.
• I have signed my commits before making this PR
• My code follows the code style of this project. See GREP1.md.
• I have updated the documentation where necessary.
• I have added tests to cover my changes, and all previous tests pass. (No new APIs.)

I suspect the documentation is more user-facing and isn't affected by the changes to the plotting API, but as I'm not sure, I left that unchecked. If there's any documentation changes needed, I'd appreciate if someone can point me in the direction of what to change; thanks!

[willcode]

Converted to draft - looks like a work in progress.

[mwoehlke-kitware]

looks like a work in progress

There were a few warnings left in modules I didn't previously have building locally. Should be fixed now.

[willcode]

Fedora 40 compiler seems to pick up a few more:

https://github.com/gnuradio/gnuradio/actions/runs/9086403135/job/24972029828?pr=7338#step:6:528

[mwoehlke-kitware]

Fedora 40 compiler seems to pick up a few more

Interesting!

/__w/gnuradio/gnuradio/gr-blocks/lib/wavfile_sink_impl.cc:267:24: error: cast from 'const void *' to 'float *' drops const qualifier [-Werror,-Wcast-qual]
  267 |     auto in = (float**)&input_items[0];
      |                        ^

This definitely looks legitimate, but it seems GCC 13.2.1 doesn't detect it. Probably because it's a cast of void** rather than the more typical void*? (Given that the warning text seems to be bugged, that seems somewhat likely.)

Anyway, hopefully fixed! (Also, hopefully when you said "few" you really meant "one", although since it seems I need CI to find these, I guess we won't know for certain until it passes CI.)

[willcode]

Looks good. The other failures are unrelated. I just need to take a little time to read all the changes.

[mwoehlke-kitware]

No hurry!

FYI, this does make breaking changes to:

• [fec] generic_{en,de}coder::generic_work (existing overloads will break)
• [qtgui] *DisplayPlot::plotNewData (breaking argument type change)
• [qtgui] *UpdateEvent::get*Points (return type changed)

I'm not sure if any of those are "user visible", or if you care, but something to keep in mind when considering whether or not to back-port.

[willcode]

Thanks, I'll make sure to look carefully at those. For 3.10 (really for the rest of the life of 3.X) anything that breaks backward compatibility probably will not be merged onto main, as we have no plans to make a new non-backward-compatible 3.X release. There's some gray area there if it's something we're pretty sure is used only in-tree.

The ones you mention are probably only used in-tree .

[willcode]

There is some possibility that an OOT subclasses the en/decoder but it seems unlikely enough that we can merge to main and see what happens.