Would it be possible to add more generic replacement for the gone cfamily.cpp23.enabled setting, perhaps even add a c++-latest et. al. target?
GCC 15 has changed__STDC_VERSION__ for C23 to 202311L, so the scanner will refuse to run. When I attempted to run the scanner a few moths ago, then the problem was __cplusplus, so a similar story and no analysis. I have no desire to do a hack, given this is non-free software, where some wrapper changes the reported version macros.
I have a large code base, so it would be useful to perform static analysis even if the scanner would not be able to scan everything. Also, targetting the latest standard does not mean that the code could not be using the age old practices. Just that one is not accidentally using features, that are to be deprecated in the future, i.e. heading to a dead end.
With the current approach no analysis will ever be possible, as the scanner is essentially always outdated compared to the compiler.
thank you for raising this point. It is not just a matter of adding a property and enabling it; when we give the possibility to analyze with new standards like cpp23 and c23, we want to make sure that the quality of the analysis is of good level.
I created a ticket to add support for c23: [CPP-5300] - Jira
We are going to tackle it soon; in the most optimistic case, it would be towards the end of June with SonarQube 10.6.
Thank you. I understand, that it is desirable to keep the analysis at high quality, or otherwise the signal-to-noise ratio becomes intolerable (to a point beyond which analysis reports are completely ignored).
However, I think the current approach is a bit too pedantic and throws in the towel too early. In this case, there will be zero analysis (without fooling the scanner) prior the said optimistic date, but it is not like the world would stay still in the meantime (both code base and tooling alike).
I’d much rather see a quality gate, that would be triggered if the language target is not yet known by the scanner. This would likely satisfy MISRA-C et. al. folks.
Also, the reported versions could to be used to detect out of date compilers (detect well-known versions, tolerate unknown versions). Say, if (and when) __STDC_VERSION__ will change for the finalized C23, then any 202311L should be treated outdated as a later version exists (might happen if development and CI/CD pipelines get accidentally out of sync).
Unless the underlying principle is changed, the issue will simply repeat itself - it is not like C and C++ standards are stalled anymore, which was case a decade ago. I think it is similar case with any modern software (especially as a service); not without its issues, but also not possible to advance if everyone stays behind.