Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MONGOCRYPT-783 address -Wformat warnings #970

Merged
merged 8 commits into from
Feb 28, 2025

Conversation

eramongodb
Copy link
Contributor

Related to MONGOCRYPT-783.

The -Wformat-nonliteral warning warns when the provided format string cannot be checked at compile-time for correctness or security issues. Currently, there are 2 warnings for GCC and 6 warnings for Clang. Addressing these initial warnings reveal an additional 6 for GCC and 1 for Clang. Addressing these warnings converts all format strings in the codebase into string literals which can be checked at compile-time. These new compile-time checks enabled the following warnings:

  • Clang:
    • -Wformat-security: 28 unique, 38 total.
    • -Wformat-extra-args: 1 unique, 1 total.
    • -Wformat: 74 unique, 197 total.
  • GCC:
    • -Wformat-security: 29 unique, 39 total.
    • -Wformat-extra-args: 1 unique, 1 total.
    • -Wformat=: 2 unique, 2 total.

To address -Wformat warnings for enumerators (e.g. bson_type_t), arguments are cast to int along with %d specifiers, as most enumerators are expected/assumed to be representable by int.

Aside from straightforward format specifier fixes, functions that accept a format string are given format(__printf__) attributes (addressing most -Wformat-nonliteral warnings). This motivated the addition of *_from_str equivalents of *_from_json test utilities that do not have the formatting requirement (addressing most -Wformat-security warnings).

Note

This PR introduces new -Wformat= GCC warnings due to use of %z in kms_request.c. These new warnings are resolved by #969.

@eramongodb eramongodb requested a review from kevinAlbs February 27, 2025 22:56
@eramongodb eramongodb self-assigned this Feb 27, 2025
Copy link
Contributor

@kevinAlbs kevinAlbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The warning fixes are much appreciated.

"cm" : {"$numberLong" : "7"}
});
bson_t *const as_bson = TMP_BSON(template, spec_json_in);
// Preserve `%s` which gets incorrectly formatted to `% s`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider using TMP_BSONF to avoid need to disable/re-enable clang-format:

#define PLACEHOLDER_TEMPLATE                                                                                           \
    RAW_STRING({                                                                                                       \
        "t" : {"$numberInt" : "1"},                                                                                    \
        "a" : {"$numberInt" : "4"},                                                                                    \
        "ki" : {"$binary" : {"base64" : "EjRWeBI0mHYSNBI0VniQEg==", "subType" : "04"}},                                \
        "ku" : {"$binary" : {"base64" : "q83vqxI0mHYSNBI0VniQEg==", "subType" : "04"}},                                \
        "v" : MC_STR,                                                                                                  \
        "cm" : {"$numberLong" : "7"}                                                                                   \
    })

    bson_t *const as_bson = TMP_BSONF(PLACEHOLDER_TEMPLATE, spec_json_in);

Though notably TMP_BSONF is a printf-like function but does not benefit from the same warnings. I expect it is OK for testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed to use MC_BSON with TMP_BSON_STR instead of MC_STR due to MC_STR being substituted as "<str>", whereas spec_json_in is a JSON string, so the expanded JSON looks like: "v": "{ ... }" when it should be "v": { ... }.

@eramongodb eramongodb merged commit 15d82f5 into mongodb:master Feb 28, 2025
7 of 8 checks passed
@eramongodb eramongodb deleted the crypt-783-format branch February 28, 2025 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants