This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

> 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++.

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?

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]