On 08/08/18 17:51, Martin Sebor wrote:
> On 08/07/2018 11:46 AM, Richard Biener wrote:
>>
>> Pointer types carry no information in GIMPLE.
>
> So what do you suggest as a solution?
>
> The strlen optimization can be decoupled from warnings and
> disabled, and the aggressive loop optimization can be disabled
> altogether. But the same issue affects all string functions
> with _FORTIFY_SOURCE=2. The modified example below aborts at
> runime (and gets diagnosed by -Wstringop-overflow).
>
> GCC certainly needs to generate valid object code for valid
> source code. But keeping track of object type information
> is also important for correctness and security, as has been
> done by _FORTIFY_SOURCE and by many middle-end warnings.
> When accurate, it also benefits optimization.
>
> What can we do to make it more reliable? Would annotating
> placement new solve the problem? If not, what would?
>
> Martin
>
> #include <new>
> #include <string.h>
>
> struct S { int x; unsigned char a[1]; char b[64]; };
>
> void foo (S *p)
> {
> char *q = new ((char*)p->a) char [16];
>
> strcpy (q, "12345678"); // abort here
> }
>
> int main ()
> {
> foo (new S);
> }
>
I quote Jakub's E-mail from 07/31/18 08:38:
"Note that _FORTIFY_SOURCE=2 is the mode that goes beyond what the standard
requires, imposes extra requirements. So from what this mode accepts or
rejects we shouldn't determine what is or isn't considered valid."
So just use _FORTIFY_SOURCE=1 ?
But what would be good to improve in _FORTIFY_SOURCE is, intercepting
strlen to catch cases early, where the char buffer is not zero terminated.
Bernd.
