diff options
| author | Kaleb S. KEITHLEY <kkeithle@redhat.com> | 2017-09-14 13:33:09 -0400 |
|---|---|---|
| committer | Amar Tumballi <amarts@redhat.com> | 2018-07-23 03:01:10 +0000 |
| commit | fd8f712f31227ebfc3ecca63a7a3a5c3f15727d9 (patch) | |
| tree | 85d9640f15dac663c0aac2fbe532ecd1962bfd39 /libglusterfs/src/syncop.c | |
| parent | 621138ce763eda8270d0a4f6d7209fd50ada8787 (diff) | |
core (named threads): flood of -Wformat-truncation warnings with gcc-7.1
Starting in Fedora 26 which has gcc-7.1.x, -Wformat-trunction is enabled
with -Wformat, resulting in a flood of new warnings. This many warnings
is a concern because it makes it hard(er) to see other warnings that
should be addressed.
An example is at
https://kojipkgs.fedoraproject.org//packages/glusterfs/3.12.0/1.fc28/data/logs/x86_64/build.log
For more info see https://review.gluster.org/#/c/18267/
I can't find much (or good) documentation on the heuristics the
compiler uses for this warning. In the case of printing integer types
it appears it looks at the available space in the destination and the
range of values for the variable and/or its type.
To address the specific question about why 0x3ff versus 0xfff to mask
the value, either would suffice to hint to the compiler that the
printed value will fit in three characters. But the loop is from
0...1023 (or 0...0x3ff if you prefer) so I chose that as a more
"accurate" mask to use as it exactly matches the range of values of
the loop.
Fixes: bz#1492847
Change-Id: I6e309ba42159841131d8241bfc0566ef09e00aa9
Diffstat (limited to 'libglusterfs/src/syncop.c')
| -rw-r--r-- | libglusterfs/src/syncop.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libglusterfs/src/syncop.c b/libglusterfs/src/syncop.c index 3db6fae6b00..767d2ef6853 100644 --- a/libglusterfs/src/syncop.c +++ b/libglusterfs/src/syncop.c @@ -733,7 +733,7 @@ syncenv_scale (struct syncenv *env) env->proc[i].env = env; snprintf (thread_name, sizeof(thread_name), - "%s%d", "sproc", env->procs); + "sproc%03hx", (env->procs & 0x3ff)); ret = gf_thread_create (&env->proc[i].processor, NULL, syncenv_processor, &env->proc[i], thread_name); |