PING [PATCH] warn for strlen of arrays with missing nul (PR 86552, 86711, 86714) )

[Jeff Law]

On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
> On 08/02/18 15:26, Bernd Edlinger wrote:
>>>
>>>    /* If the length can be computed at compile-time, return it.  */
>>> -Â  len = c_strlen (src, 0);
>>> +Â  tree array;
>>> +Â  tree len = c_strlen (src, 0, &array);
>>
>> You know the c_strlen tries to compute wide character sizes,
>> but strlen does not do that, strlen (L"abc") should give 1
>> (or 0 on a BE machine)
>> I wonder if that is correct.
>>
> [snip]
>>>
>>> Â static tree
>>> -fold_builtin_strlen (location_t loc, tree type, tree arg)
>>> +fold_builtin_strlen (location_t loc, tree fndecl, tree type, tree arg)
>>> Â {
>>> Â Â  if (!validate_arg (arg, POINTER_TYPE))
>>> Â Â Â Â  return NULL_TREE;
>>> Â Â  else
>>> Â Â Â Â  {
>>> -Â Â Â Â Â  tree len = c_strlen (arg, 0);
>>> -
>>> +Â Â Â Â Â  tree arr = NULL_TREE;
>>> +Â Â Â Â Â  tree len = c_strlen (arg, 0, &arr);
>>
>> Is it possible to write a test case where strlen(L"test") reaches this point?
>> what will c_strlen return then?
>>
> 
> Yes, of course it is:
> 
> $ cat y.c
> int f(char *x)
> {
>    return __builtin_strlen(x);
> }
> 
> int main ()
> {
>    return f((char*)&L"abcdef"[0]);
> }
FWIW, I've twiddled this a bit and included it in Martin's patch for
86711/86714.  THe proper return value is 0 or 1 depending on endianness.


Jeff