Fightwarn - macos llvm - nonliteral format strings#885
Merged
jimklimov merged 33 commits intonetworkupstools:masterfrom Nov 25, 2020
Merged
Fightwarn - macos llvm - nonliteral format strings#885jimklimov merged 33 commits intonetworkupstools:masterfrom
jimklimov merged 33 commits intonetworkupstools:masterfrom
Conversation
jimklimov
added
the
ready / code review
|
This pull request introduces 1 alert when merging 1396c273c5aadebd4e232b2fc67e92c930215964 into 27e1507 - view on LGTM.com new alerts:
|
Member
Author
|
Error reports from clang were cut short by their reporting limits, some more "appeared" in view after the cleanup. PR would grow :) |
…tring in this case
…t string in these cases
…os for cleaner fencing (nonliteral format strings)
…t string in this case
…acros for cleaner fencing (nonliteral format strings)
…at string in this case
…ros for cleaner fencing (nonliteral format strings)
…ros for cleaner fencing (nonliteral format strings)
…lem, and do not warn about nonliteral format string in this case
…rt macros for cleaner fencing (nonliteral format strings)
…ormat string in this case
…macros for cleaner fencing (nonliteral format strings)
… macros for cleaner fencing (nonliteral format strings)
…at string in these cases
…ros for cleaner fencing (nonliteral format strings)
…t macros for cleaner fencing (nonliteral format strings)
…iteral format string in these cases
…support macros for cleaner fencing (nonliteral format strings)
…t nonliteral format string in these cases
…gured-support macros for cleaner fencing (nonliteral format strings)
…eral format string in these cases
…pport macros for cleaner fencing (nonliteral format strings)
… string in this case
…ured-support macros for cleaner fencing (nonliteral format strings)
…bout nonliteral format string in these cases
…nfigured-support macros for cleaner fencing (nonliteral format strings)
…at string in this case
…igured-support macros for cleaner fencing (nonliteral format strings)
jimklimov
force-pushed
the
fightwarn-macos-llvm-nonliteral
branch
from
1396c27 to
659b288
Compare
|
This pull request introduces 1 alert when merging 659b288 into 58fff85 - view on LGTM.com new alerts:
|
Member
Author
|
Several more cases to go, but will go in another PR later, to have gains now and to keep changesets small. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows up from #823 and #844 to address warnings from clang10 on MacOS builds: NUT extensively uses string variables from tables or calculated at runtime to pass into various likes of
snprintf()and NUT's own routines with fmt+varargs syntax.This PR highlights such cases of intentional use of non-literal format strings with pragmas to quiesce GCC and CLANG warnings for this.
The main possible point of PR review is to double-check if these cases (now wrapped in pragmas, sometimes spanning large blocks of code with many
snprintfs inside) are all intentional and unavoidable. Otherwise, there is little change from previous state of codebase (one avoidable case avoided), so this PR is not likely to break anything :)