On Wed, 1 Aug 2018, Bernd Edlinger wrote: > > The change to have all STRING_CSTs NUL terminated (but that NUL > > termination not necessarily inclided in STRING_LENGTH) is a good > > one. > > > > I'm not sure how we can reliably verify NUL termination after the > > fact though and build_string already makes sure to NUL terminate > > STRING_CSTs. So if GO strings are not NUL terminated then > > the STRING_CSTs still are. > > The advantage is that there are less variations how string literals look > like in the middle end. We will have a simple way to determine if > a string literal is NUL terminated or not. And checking that property > in varasm.c is exactly the right thing to do. > > String literals always have an array_type which may be shorter > than TREE_STRING_LENGTH, but that chops off only exactly > one wide character nul. Otherwise if the array_type is equal or larger, > we know for sure the value is nul terminated. In the middle-end > we can easily determine if a string is not NUL terminated by: > > compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)), > TREE_STRING_LENGTH (init)) < 0 > > I did use that already in my patch for pr86711.
Hmm. How does that tell you whether the string is NUL terminated? TREE_STRING_LENGTH includes the NUL termination and if it is a significant char then TYPE_SIZE_UNIT should as well. Isn't a proper test to look at TREE_STRING_POINTER[TREE_STRING_LENGTH - 1] (for HOST_CHAR_BITS strings)? Relying on the type here looks somewhat fragile to me. Abstracting a string_cst_nul_terminated_p () helper would be a good idea I guess. I realize using strlen(TREE_STRING_POINTER) doesn't work because of embedded NULs. > Additionally not having oversize string constants produced > by the front ends, where the extra characters are good for nothing, > also helps to improve correctness. > > > Bernd. > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
