On 05/22/2018 07:40 PM, Martin Sebor wrote: > Here's another small refinement to -Wstringop-truncation to > avoid diagnosing more arguably "safe" cases of strncat() that > match the expected pattern of > > strncat (d, s, sizeof d - strlen (d) - 1); > > such as > > extern char a[4]; > strncat (a, "12", sizeof d - strlen (a) - 1); > > Since the bound is derived from the length of the destination > as GCC documents is the expected use, the call should probably > not be diagnosed even though truncation is possible. > > The trouble with strncat is that it specifies a single count > that can be (and has been) used to specify either the remaining > space in the destination or the maximum number of characters > to append, but not both. It's nearly impossible to tell for > certain which the author meant, and if it's safe, hence all > this fine-tuning. I suspect this isn't the last tweak, either. > > In any event, I'd like to commit the patch to both trunk and > gcc-8-branch. The bug isn't marked regression but I suppose > it could (should) well be considered one. > > Martin > > gcc-85700.diff > > > PR tree-optimization/85700 - Spurious -Wstringop-truncation warning with > strncat > > gcc/ChangeLog: > > PR tree-optimization/85700 > * gimple-fold.c (gimple_fold_builtin_strncat): Adjust comment. > * tree-ssa-strlen.c (is_strlen_related_p): Handle integer subtraction. > (maybe_diag_stxncpy_trunc): Distinguish strncat from strncpy. > > gcc/testsuite/ChangeLog: > > PR tree-optimization/85700 > * gcc.dg/Wstringop-truncation-3.c: New test. OK for the trunk. Sorry for the delay.
I don't see that strong of a case for backporting -- the distro rebuilds with gcc-8 didn't trip over it (at least not in a -Werror build). It doesn't fix a codegen issue and we've only got the one report (unknown what source the report originated with). But you can certainly ask Jakub or Richi. jeff
