| Message ID | AM5PR0701MB2657F69CF7F49AAB556539B4E4360@AM5PR0701MB2657.eurprd07.prod.outlook.com |
|---|---|
| State | New |
| Headers | show |
| Series | [PATCHv2] Handle overlength strings in C++ FE | expand |
On Fri, Aug 24, 2018 at 4:02 PM, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote: > Hi! > > > This is an alternative approach to handle overlength strings in the C++ FE. > > The difference to the previous version is that overlength > STRING_CST never have a longer TREE_STRING_LENGTH than the TYPE_DOMAIN. > And those STRING_CSTs are thus no longer zero terminated. > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? > + *value_ptr = len1++; Is a trailing NUL actually needed for this data structure, given that the length is explicitly provided? If it is, you also need to add one at the end of the buffer. Jason
On 08/30/18 00:17, Jason Merrill wrote: > On Fri, Aug 24, 2018 at 4:02 PM, Bernd Edlinger > <bernd.edlinger@hotmail.de> wrote: >> Hi! >> >> >> This is an alternative approach to handle overlength strings in the C++ FE. >> >> The difference to the previous version is that overlength >> STRING_CST never have a longer TREE_STRING_LENGTH than the TYPE_DOMAIN. >> And those STRING_CSTs are thus no longer zero terminated. >> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >> Is it OK for trunk? > >> + *value_ptr = len1++; > > Is a trailing NUL actually needed for this data structure, given that > the length is explicitly provided? If it is, you also need to add one > at the end of the buffer. > No, it's not needed. So I'll drop that hunk. Bernd.
On Thu, Aug 30, 2018 at 2:55 AM, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote: > On 08/30/18 00:17, Jason Merrill wrote: >> On Fri, Aug 24, 2018 at 4:02 PM, Bernd Edlinger >> <bernd.edlinger@hotmail.de> wrote: >>> Hi! >>> >>> >>> This is an alternative approach to handle overlength strings in the C++ FE. >>> >>> The difference to the previous version is that overlength >>> STRING_CST never have a longer TREE_STRING_LENGTH than the TYPE_DOMAIN. >>> And those STRING_CSTs are thus no longer zero terminated. >>> >>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >>> Is it OK for trunk? >> >>> + *value_ptr = len1++; >> >> Is a trailing NUL actually needed for this data structure, given that >> the length is explicitly provided? If it is, you also need to add one >> at the end of the buffer. > > No, it's not needed. > So I'll drop that hunk. The rest of the patch is OK. Jason
2018-08-01 Bernd Edlinger <bernd.edlinger@hotmail.de> * typeck2.c (digest_init_r): Fix overlength strings. * vtable-class-hierarchy.c (build_key_buffer_arg): Make string literal NUL terminated. Index: gcc/cp/typeck2.c =================================================================== --- gcc/cp/typeck2.c (revision 263807) +++ gcc/cp/typeck2.c (working copy) @@ -1116,8 +1116,13 @@ digest_init_r (tree type, tree init, int nested, i counted in the length of the constant, but in C++ this would be invalid. */ if (size < TREE_STRING_LENGTH (init)) - permerror (loc, "initializer-string for array " - "of chars is too long"); + { + permerror (loc, "initializer-string for array " + "of chars is too long"); + + init = build_string (size, TREE_STRING_POINTER (init)); + TREE_TYPE (init) = type; + } } return init; } Index: gcc/cp/vtable-class-hierarchy.c =================================================================== --- gcc/cp/vtable-class-hierarchy.c (revision 263807) +++ gcc/cp/vtable-class-hierarchy.c (working copy) @@ -738,7 +738,7 @@ build_key_buffer_arg (tree base_ptr_var_decl) tree ret_value; /* Set the len and hash for the string. */ - *value_ptr = len1; + *value_ptr = len1++; value_ptr++; *value_ptr = hash_value;