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

Convert miscellaneous instances of sprintf to snprintf #3077

Open
wants to merge 1 commit into
base: 10.5
Choose a base branch
from

Conversation

tgross35
Copy link
Contributor

Remove use of sprintf in favor of snprintf where indicated by deprecation warnings.

  • The Jira issue number for this PR is: MDEV-______

Description

This is a portion of #2958

Release Notes

None needed

How can this PR be tested?

Compile with -Wdeprecated-declarations (I believe it is enabled by default for the relevant files) and use a version of libc that marks sprintf deprecated.

Basing the PR against the correct MariaDB version

  • This is a new feature and the PR is based against the latest MariaDB development branch.
  • This is a bug fix and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

  • I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
  • For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

client/mysqladmin.cc Outdated Show resolved Hide resolved
plugin/type_inet/sql_type_inet.cc Outdated Show resolved Hide resolved
@dlenski
Copy link
Contributor

dlenski commented Feb 20, 2024

As in #3076 (comment), it appears that the buildbot/CI failures on this PR are not due to changes in the PR, but rather they are "preexisting" failures on the upstream source branch.

@tgross35 tgross35 force-pushed the remove-sprintf-client-backup branch 3 times, most recently from 208739c to 0d71656 Compare February 25, 2024 03:29
@tgross35
Copy link
Contributor Author

This one should be ready for another look when you get the chance @dlenski

Comment on lines +503 to +496
int res= snprintf(p, dstsize_available, "%x", ipv6_words[i]);
DBUG_ASSERT(res >= 0);
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think the return value of snprintf tells you anything useful here. https://linux.die.net/man/3/snprintf#:~:text=Concerning%20the%20return%20value%20of,large%20enough.

Copy link
Contributor Author

@tgross35 tgross35 Feb 26, 2024

Choose a reason for hiding this comment

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

It can return -1 if printing to a file fails or if there is an error in the format string. No chance of that as-is, but figure it's a trivial check to make sure we never accidentally increment the available size.

I only added this check in cases where we actually use the result, though it wouldn't be a terrible thing (if annoying) to have elsewhere

dstsize_available= dstend - p;
int res= snprintf(p, dstsize_available, "%x", ipv6_words[i]);
DBUG_ASSERT(res >= 0);
p += res;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should dstsize_available be decreased here as well? E.g. p += res; dstsize_available -= res;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually it doesn't have to be set at all since it is only read once per block, I removed line 502 here. The other blocks do not update dstsize_available after doing the pointer math.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Must have just been flaky, all required tests pass now

@tgross35 tgross35 force-pushed the remove-sprintf-client-backup branch 4 times, most recently from e378995 to e29c8a0 Compare February 27, 2024 23:14
@tgross35 tgross35 force-pushed the remove-sprintf-client-backup branch from e29c8a0 to 08b950f Compare March 8, 2024 19:38
Copy link
Contributor

@LinuxJedi LinuxJedi left a comment

Choose a reason for hiding this comment

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

I don't see any initial problems with this. Many thanks! Although this could go against 10.5 instead, cover more versions.

@tgross35 tgross35 force-pushed the remove-sprintf-client-backup branch from 08b950f to cf87f76 Compare April 5, 2024 01:25
Remove use of `sprintf` in favor of `snprintf` where indicated by deprecation
warnings.

Signed-off-by: Trevor Gross <[email protected]>
@tgross35 tgross35 force-pushed the remove-sprintf-client-backup branch from cf87f76 to bfda187 Compare April 5, 2024 01:41
@tgross35 tgross35 changed the base branch from 11.5 to 10.5 April 5, 2024 01:41
@tgross35
Copy link
Contributor Author

tgross35 commented Apr 5, 2024

@LinuxJedi thanks, I changed the base to 10.5.

Side question, about how often do syncs among the versions happen?

@@ -1428,10 +1428,12 @@ static void usage(void)
version Get version info from server");
}

#define SHOW_MSG_LEN (FN_REFLEN + 20)
Copy link
Member

Choose a reason for hiding this comment

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

Why introduce this #define SHOW_MSG_LEN? It only makes it harder to understand the code, that the right size is being passed to snprintf() (as opposed to just sizeof()), and that the buffer is large enough that it will not be truncated and corrupt the command to be contructed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right, I was thinking this existed elsewhere too somehow

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually this was by request to remove the magic values #3077 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

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

To be fair to @tgross35, our coding standards document is unclear for this specific instance. We should maybe update that section. In other projects, this would be the way to do things, maybe with a comment.

@@ -1428,10 +1428,12 @@ static void usage(void)
version Get version info from server");
}

#define SHOW_MSG_LEN (FN_REFLEN + 20)
#define UINPUT_BUF_LEN 10
Copy link
Member

Choose a reason for hiding this comment

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

Why introduce this #define UINPUT_BUF_LEN? This is unrelated to sprintf/snprintf(), should be done as a separate patch (or why do it at all, the code is simpler without the #define, it's only used in one place)

Comment on lines +241 to +242
snprintf(safe_process_name, SAFE_PROCESS_NAME_LEN,
"safe_process[%ld]", (long) own_pid);
Copy link
Member

Choose a reason for hiding this comment

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

Again, don't introduce SAFE_PROCESS_NAME_LEN. It only makes it harder to see that the buffer size is correct for the string being constructed, and that the correct length is passed to sprintf() (as opposed to using sizeof())

@knielsen
Copy link
Member

knielsen commented Apr 9, 2024

Also what about testing? The patch contains no test cases.

The mysqladmin changes have a restriction on the database name of FN_REFLEN. It needs to be tested that database names up to this length work, and longer (eg. FN_REFLEN+1) throw an error higher in the code, so the snprintf() doesn't silently truncate the name and send a corrupted command to the server.

If this is already covered by existing tests, it would be good to mention this in the commit comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants