Bug 81436

Summary: missing -Wstringop-overflow on strncat to a zero-size buffer
Product: gcc Reporter: Martin Sebor <msebor>
Component: tree-optimizationAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: dmalcolm, dodji, egallager
Priority: P3 Keywords: diagnostic
Version: 8.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: 10.0, 8.2.0, 9.1.0 Last reconfirmed: 2020-04-22 00:00:00
Bug Depends on:    
Bug Blocks: 88443    

Description Martin Sebor 2017-07-13 22:52:25 UTC
Strncat always appends a terminating NUL to the end of the copied string.  Therefore, it's never safe to call it with a destination of zero size.  Such calls should be diagnosed by -Wstringop-overflow but in GCC 7.1 they are not.

$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
void sink (void*);

void f (const char *s, int n)
{
  char d[1];

  __builtin_strncat (d + 1, s, n);   // missing -Wstringop-overflow

  sink (d);
}

;; Function f (f, funcdef_no=0, decl_uid=1818, cgraph_uid=0, symbol_order=0)

f (const char * s, int n)
{
  char d[1];
  long unsigned int _1;

  <bb 2> [100.00%] [count: INV]:
  _1 = (long unsigned int) n_2(D);
  __builtin_strncat (&MEM[(void *)&d + 1B], s_4(D), _1);
  sink (&d);
  d ={v} {CLOBBER};
  return;

}
Comment 1 Eric Gallager 2017-08-30 01:56:30 UTC
Confirmed.
Comment 2 Eric Gallager 2018-11-11 03:17:48 UTC
cc-ing diagnostics maintainers
Comment 3 Martin Sebor 2018-11-11 17:16:44 UTC
Eric, thanks for putting so much effort into helping triage and make progress on these bugs!  FWIW, I think the diagnostic maintainers are mainly focused on the design and implementation of diagnostic infrastructure, not so much on deficiencies in its client code, so CC'ing them on bugs like this is probably not going to help move them along.  (I'll let David and/or Dodji correct me if I'm wrong here.)
Comment 4 Eric Gallager 2018-11-12 00:59:53 UTC
(In reply to Martin Sebor from comment #3)
> Eric, thanks for putting so much effort into helping triage and make
> progress on these bugs!  FWIW, I think the diagnostic maintainers are mainly
> focused on the design and implementation of diagnostic infrastructure, not
> so much on deficiencies in its client code, so CC'ing them on bugs like this
> is probably not going to help move them along.  (I'll let David and/or Dodji
> correct me if I'm wrong here.)

OK, would there be someone else who'd be better to ask for help for bugs in this portion of the compiler then?
Comment 5 Martin Sebor 2020-04-22 21:09:54 UTC
No change in GCC 10.