Re: [PATCH] convert braced initializers to strings (PR 71625)

[Martin Sebor <msebor@gmail.com>]

On 07/31/2018 07:38 AM, Jason Merrill wrote:
> On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor <msebor@gmail.com> wrote:
>> The middle-end contains code to determine the lengths of constant
>> character arrays initialized by string literals.  The code is used
>> in a number of optimizations and warnings.
>>
>> However, the code is unable to deal with constant arrays initialized
>> using the braced initializer syntax, as in
>>
>>   const char a[] = { '1', '2', '\0' };
>>
>> The attached patch extends the C and C++ front-ends to convert such
>> initializers into a STRING_CST form.
>>
>> The goal of this work is to both enable existing optimizations for
>> such arrays, and to help detect bugs due to using non-nul terminated
>> arrays where nul-terminated strings are expected.  The latter is
>> an extension of the GCC 8 _Wstringop-overflow and
>> -Wstringop-truncation warnings that help detect or prevent reading
>> past the end of dynamically created character arrays.  Future work
>> includes detecting potential past-the-end reads from uninitialized
>> local character arrays.
>
>>   && TYPE_MAIN_VARIANT (TREE_TYPE (valtype)) == char_type_node)
>
> Why? Don't we want this for other character types as well?

It suppresses narrowing warnings for things like

   signed char a[] = { 0xff };

(there are a couple of tests that exercise this).

At the same time, STRING_CST is supposed to be able to represent
strings of any integer type so there should be a way to make it
work.  On the flip side, recent discussions of changes in this
area suggest there may be bugs in the wide character handling of
STRING_CST so those would need to be fixed before relying on it
for robust support.

In any case, if you have a suggestion for how to make it work for
at least the narrow character types I'll adjust the patch.

Martin