On 08/07/2018 02:57 AM, Jason Merrill wrote:
> On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor <msebor@gmail.com> wrote:
>> 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).
>
> Why is plain char different in this respect?  Presumably one of
>
> char a[] = { -1 };
> char b[] = { 0xff };
>
> should give the same narrowing warning, depending on whether char is signed.

Right.  I've added more tests to verify that it does.

>> 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.
>
> I suppose braced_list_to_string should call check_narrowing for C++.

I see.  I've made that change.  That has made it possible to
convert arrays of all character types.  Thanks!

> Currently it uses tree_fits_shwi_p (signed host_wide_int) and then
> stores the extracted value in a host unsigned int, which is then
> converted to host char.  Does the right thing happen for -fsigned-char
> or targets with a different character set?

I believe so.  I've added tests for these too (ASCII and EBCDIC)
and also changed the type of the extracted value to HWI to match
(it doesn't change the results of the tests).

Attached is an updated patch with these changes plus more tests
as suggested by Joseph.

Martin