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
Fix Issue 20644 - Invalid printf deprecation for ubyte passed to "%hhu" #10920
Conversation
Thanks for your pull request and interest in making D better, @Luhrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla references
Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + dmd#10920" |
It seems like the wrong fix if dlang/druntime#2988 is necessary. Please also add the test case from the bug report. |
@rainers why ? It's not very clear what we should do with types which are promoted to
Edit: Just saw you comment in dlang/druntime#2988 - using the 2nd. |
a60cb5a
to
88a7b4a
Compare
Because none of the C compilers complain about it.
yes, both should not emit a message with %d. |
This is a regression from the merging of chkprintf.d with chkscanf.d. I suggest going over chkprintf.d and seeing why it worked correctly, as this fix doesn't look like that. |
@WalterBright That's because Should we check for the correct use of these formats or simply bypass it like you did ? |
65dae52
to
ccfb7bd
Compare
My implementation was pedantically correct according to the C Standard. If I made a mistake with that and am proven wrong, which is entirely possible, that should be a separate PR. But this particular behavior is not a mistake, because variadics always undergo the usual arithmetic promotions. In general, refactorings must not include bug fixes and/or enhancements. I stress this again and again. Refactorings, bug fixes and enhancements should go in separate PRs. This regression slipped into a PR that was a bug fix and a refactoring and an enhancement, and it was done with no comment about including a bug fix. I have a lot of experience with refactorings, bug fixes, and enhancements. Things go much better with much less time wasted chasing regressions when they are separate PRs. |
No description provided.