On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor <mse...@gmail.com> wrote: > On 07/31/2018 07:38 AM, Jason Merrill wrote: >> >> On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor <mse...@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