This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Make GO string literals properly NUL terminated
- From: Richard Biener <rguenther at suse dot de>
- To: Ian Lance Taylor <iant at golang dot org>
- Cc: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 1 Aug 2018 09:01:17 +0200 (CEST)
- Subject: Re: [PATCH] Make GO string literals properly NUL terminated
- References: <AM5PR0701MB26570687DEEC36D3BE2F21F4E42E0@AM5PR0701MB2657.eurprd07.prod.outlook.com> <CAKOQZ8xqg-bC-EFyizZHmybi43K3qgiv+qtOuCSSe_kS8xo6Sw@mail.gmail.com> <AM5PR0701MB2657B4206C8952D1088089EAE42E0@AM5PR0701MB2657.eurprd07.prod.outlook.com> <CAKOQZ8y3EEBXw0LSsC9bhVymv=h2vwH3N3uYK9fbu3T-K12FJw@mail.gmail.com>
On Tue, 31 Jul 2018, Ian Lance Taylor wrote:
> On Tue, Jul 31, 2018 at 9:19 AM, Bernd Edlinger
> <firstname.lastname@example.org> wrote:
> > 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.
The change to have all STRING_CSTs NUL terminated (but that NUL
termination not necessarily inclided in STRING_LENGTH) is a good
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.
Richard Biener <firstname.lastname@example.org>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)