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.
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
MDEV-35599: Replace (
u
)llstr()
with%llu
/d
#3724base: main
Are you sure you want to change the base?
MDEV-35599: Replace (
u
)llstr()
with%llu
/d
#3724Changes from 1 commit
4dfe7cf
c6e6ef7
8ab1eaf
0af0489
8e5ae27
482aa63
7dacefe
f0bf893
d7623b3
2aa992e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
row_events
is ulonglong, that is unsigned. Were you getting a compiler error here?you wrote it's a non-goal, so I will no longer comment on signed/unsigned mismatch, but would the code compile without you fixing it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it’s impractical to track typedefs manually when we can automatically catch them by turning on
-Wformat-signedness
, so I explicitly excluded this step.From what I can tell, neither
-Wformat
nor-Wall
include-Wformat-signedness
, so issues like this continue not spawning compile warnings.I mentioned
-Wformat-signedness
as a comment of MDEV-26896.We can prioritize it here or we can push for MDEV-26896 to ship with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 Turning on
-Wconversion
(MDEV-26896) will complain about cases like these before this replacement.🧐 It will also complain about
char *ullstr(longlong value,char *buff)
because it delegates aulonglong
arg tolonglong10_to_str(value,buff,10);
which is sign-agnostic.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my_b_printf
does not support and ignores%llu
, causing segfaults here and likely erroneous outputs in other places.my_b_printf
is another one of ourprintf
alternative that formats tomy_b_write
.It only supports format specifiers
%s
,%c
,%d
/%u
and%ld
/%lu
(yes, they’re specifiers in its lexicon) and ignores others.Notably,
my_b_printf
also supports%b
and the`
flag for%s
similar tomy_snprintf
; but that’s switching to%sB
and%sQ
, whereasmy_b_printf
is a separate implementation independent of that.When I migrated
my_snprintf
users, I recognized thatmy_b_printf
isn’t part of the family and skipped over it.That meant
my_b_printf
would remain incompatible with-Wformat
and be “out of date” with the modifiedmy_snprintf
.Except
my_b_printf
is causing trouble right now.@vuvova, what shall we do about it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion — rewrite
my_b_vprintf
copying the logic frommy_vfprintf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and they will be consistent until the next time we update themy_snprintf
family.🧐 I’m not sure about that.
my_vfprintf
works by resizing its allocation until the result fits1, whereasmy_b_write
writes to a limited buffer that only flushes when full.Either case, I should mark this PR as on hold.
Footnotes
… which is not efficient; unfortunately, unlike C/C++
snprintf
,my_snprintf
doesn’t tell the number of bytes it would’ve written if the output buffer’s sufficient. ↩There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I mean,
my_b_vprintf
could write to a buffer, resizing it likemy_vfprintf
does. Agree, it's not the best approach, but fixing it would be a separate task. At the endmy_b_vprintf
would usemy_b_write
to write the buffer toIO_CACHE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have another idea.
We can modify the implementation of
my_vsnprintf
to instead build around a writer callback, saybool (*writer)(void *reference, char *string, int string_length)
that returns whether the loop should halt.When respective buffers fill up, regular
my_vsnprintf
’s callback would return a halt request, while bothmy_vfprintf
’s andmy_b_vprintf
’s would flush and carry on.Of course, because
my_vsnprintf
is divided to many subfunction components, this approach is intrusive and very complex.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. That's why it wasn't implemented yet. In particular, it wasn't implemented, when we needed
my_vfprintf
.A compromise approach — simpler than yours, more complex than what I suggested earlier — would be to make
my_vsnprint_ex
to return, as you wrote, number of bytes it would have written if the buffer were big enough. In this approachmy_vsnprint
can still return what it does now, it's a public API function and if we want to be conservative, we won't change it. But the internalmy_vsnprint_ex
can be changed to return whatever we want, andmy_vfprintf
can call it directly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌 Let’s put then on the backburner for now; I have higher-priority assignments.