[PATCH] tree-optimization/pr103961: Never compute offset for -1 size

[Jakub Jelinek]

On Tue, Jan 11, 2022 at 06:40:44PM +0530, Siddhesh Poyarekar wrote:
> Never try to compute size for offset when the object size is -1, which
> is either unknown maximum or uninitialized minimum irrespective of the
> osi->pass number.
> 
> gcc/ChangeLog:
> 
> 	PR tree-optimization/pr103961
> 	* tree-object-size.c (plus_stmt_object_size): Always avoid
> 	computing offset for -1 size.
> 
> gcc/testsuite/ChangeLog:
> 
> 	PR tree-optimization/pr103961
> 	* gcc.dg/pr103961.c: New test case.

Ok.  Martin's executable testcase would work too but only if
it would be limited to targets with glibc with __sprintf_chk in or
it would need to be linked against -lssp, so I think it is fine as is.

> +void
> +cap_to_text (int c)
> +{
> +  char buf[1572];
> +  char *p;
> +  int n, t;
> +  p = 20 + buf;
> +  for (t = 8; t--; )
> +    {
> +      for (n = 0; n < c; n++)
> +	p += sprintf (p, "a,");
> +      p--;
> +      if (__builtin_object_size (p, 1) == 0)
> +	abort ();
> +    }

Just curious, does your PR77608 patch change this such that __bos (p, 1)
is not ~(size_t)0 but 1572?
We don't know if c isn't 0, so can't count on p += sprintf (p, "a,");
actually incrementing the pointer (and unless we try to understand more
what exactly it is doing we'd need to also assume it could e.g. return -1,
and we aren't too smart about loops anyway, but if the PR77608 patch assumes
that variable bounds aren't out of bounds, then a pointer that started
as 20 + buf can be minimum buf + 0 and maximum buf + 1572.
Note, as __bos is trying to prevent exploiting UB, perhaps assuming the
pointer arithmetics or array refs aren't out of bounds isn't perfect, but
then I'd say a __bos (p, 1) == 1572 means bigger security than __bos (p, 1)
== -1 where we punt and don't check anything.

	Jakub