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