This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING [PATCH] warn for strlen of arrays with missing nul (PR 86552, 86711, 86714) )
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