-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
[RFC] Add compile-time checking of mp_printf format strings #17556
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
base: master
Are you sure you want to change the base?
Conversation
Example diagnostic:
|
df0062d
to
c39e2bd
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #17556 +/- ##
=======================================
Coverage 98.38% 98.38%
=======================================
Files 171 171
Lines 22239 22239
=======================================
Hits 21880 21880
Misses 359 359 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Code size report:
|
0153502
to
536f6fb
Compare
the plugin can also run during the gcc windows builds. I tested it locally using the cross-building steps but I assume it'd work on windows too. I won't complicate this PR by adding it, but I'd plan to add it in a subsequent PR. Some of the format string "findings" came out of me doing that locally. |
@dpgeorge Please let me know if you think this is worth pursuing. |
I did some checks in a sibling branch, and on macos, |
Plugin support on Windows/MinGW has a number of limitations and additional requirements so adding support for that would better be postponed to a subsequent PR. |
I'm mildly in favour of this. The three main things to consider would be:
I did test out this PR locally with the unix coverage build and it works well. It looks like this did find same cases of |
Thanks for the feedback. I did consider trying to automatically enable the plugin if possible, and disable it if not; but this looked fragile. One option would be to switch it to requring the plugin to be enabled (and enabling it during as many CI jobs as possible). A developer who runs into a diagnostic during CI would then have the option to install the plugin and use ENABLE locally, or whether to make a stab at fixing it and submit another job to CI. Would it make more sense to work on fixing the diagnosed format problems in a separate PR (some of them do seem to be "real bugs" that will bite at runtime) and then bring the format checker in later? Or are you content to let the fixes and the checker land at the same time, which would make the fixes later? Final question: C99 "solves" some format string problems by using macros like PRId64 that expand to a correct format string depending on the underlying types (e.g., it might expand to "lld" on an LLp64 sytem or "ld" on an LP64 system). What do you think of introducing such macros in micropython for mp_int_t/mp_uint_t? It looks like there's also a problem integer-printing pointer-width types which leads to the current Windows build failures (and which I'll correct).. (Some issues are getting fixed in #17538 because the problems DID turn up during CI; this branch will need to be rebased when that one goes in) |
Yes, I also thought about that. At the very least, I think the option should be in the positive tense, eg
Yes, please. That PR would be a much easier thing to review and merge.
Yes, I think that's a good idea. I have many times considered using the PRIxxx macros for all printf strings. But it's a fair bit of work to do that. But a good idea to start with them for |
My thoughts on sequencing the work:
|
990966c
to
f0a7d80
Compare
1ecc7a8
to
a171072
Compare
More sequencing: Once #17618 goes in, I'll rebase this, add XINT_FMT (the format string to print mp_int_t as hex), and use it for cell printing (@jepler objcell: Fix printing cell ID.). Once that's done and all green with the checker in this PR, I'll create a separate "fixes only" PR. |
02ff49b
to
7424d62
Compare
Rebased. I'll get it back to green, then submit a 2nd PR with "just the bug fixes". |
2ba0e92
to
7927022
Compare
10aaf68
to
484f41e
Compare
Signed-off-by: Jeff Epler <jepler@gmail.com>
.. so filter it out, similar to stm32. Signed-off-by: Jeff Epler <jepler@gmail.com>
It causes an error, so filter it out, similar to other compile-only flags. Signed-off-by: Jeff Epler <jepler@gmail.com>
Signed-off-by: Jeff Epler <jepler@gmail.com>
484f41e
to
cc58f72
Compare
OK, everything this PR depends on has been merged. I've updated the initial comment to reflect the current state of things. |
Summary
It's always nice when errors can be detected at compile time. In traditional C programs, gcc can check that the printf argument types match the printf format string. This has not been possible up to now with mp_printf, because it has both extensions to standard printf (e.g., the
%q
format type) and is missing things in standard printf (e.g.,%zd
is not supported).To that end, I have developed a GCC plugin that does this checking at compile time, and enabled it during the ci build process where possible.
Testing
I built the unix port coverage variant & ran the tests locally. The plugin itself should cause no code changes, and the code size check (which does NOT turn on the plugin) reports no size change.
A total of 45 sites in ci.sh use the new plugin.
Trade-offs and Alternatives
As a gcc plugin this can only support gcc-based toolchains. clang and proprietary compilers would not work. This does not seem important, as this feature only produces diagnostics.
The plugin is GPL licensed. I started with a GPL-licensed plugin template, and plugins need to be GPL-or-compatible in license in order to be loaded in gcc anyway. The plugin code IMO does not affect the license situation of the output object code, as you'd get the exact same code with or without the plugin.
Missing support for:
%ll
is runtime-supportedI never specifically measured the build-time impact of enabling the plugin.