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