On Tue, 31 Jul 2018, Ian Lance Taylor wrote: > On Tue, Jul 31, 2018 at 9:19 AM, Bernd Edlinger > <bernd.edlin...@hotmail.de> wrote: > > On 07/31/18 16:40, Ian Lance Taylor wrote: > >> On Tue, Jul 31, 2018 at 5:14 AM, Bernd Edlinger > >> <bernd.edlin...@hotmail.de> wrote: > >>> > >>> could someone please review this patch and check it in into the GO FE? > >> > >> I don't understand why the change is correct, and you didn't explain > >> it. Go strings are not NUL terminated. Go strings always have an > >> associated length. > >> > > > > Yes, sorry. Effectively for go this change is a no-op. > > I'll elaborate a bit. > > > > This makes it easier for the middle-end to distinguish between > > nul-terminated > > and not nul terminated strings. Especially if wide character strings > > may also may come along. > > > > In C a not nul terminated string might be declared like > > char x[2] = "12"; > > it is always a STRING_CST object of length 3, with value "12\0". > > The array_type is char[0..1] > > > > while a nul terminated string is declared like > > char x[3] = "12" > > it is also a STRING_CST object of length 3, with value "12\0" > > The array_type is char[0..2] > > > > Note however the array type is different. > > So with this convention one only needs to compare the array type > > size with the string length which is much easier than looking for > > a terminating wide character, which is rarely done right. > > > > At the end varasm.c filters the excess NUL byte away, but > > I would like to add a checking assertion there that this does not > > strip more than max. one wide character nul byte. > > Thanks, I think I should probably let this be reviewed by someone > reviewing the larger patch. The go-gcc.cc file lives in the GCC repo > and changes to it can be approved and committed by any GCC middle-end > or global maintainer. It's not part of the code copied from another > repo, which lives in gcc/go/gofrontend.
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. Bernd? Richard. > Ian > > -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
