This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Make GO string literals properly NUL terminated
On Tue, Jul 31, 2018 at 9:19 AM, Bernd Edlinger
> On 07/31/18 16:40, Ian Lance Taylor wrote:
>> On Tue, Jul 31, 2018 at 5:14 AM, Bernd Edlinger
>> <email@example.com> 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 = "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 = "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.