Re: [PATCH] Make GO string literals properly NUL terminated

[Ian Lance Taylor <iant at golang dot org>]

On Tue, Jul 31, 2018 at 9:19 AM, Bernd Edlinger
<bernd.edlinger@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.edlinger@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