This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 31 Jul 2018, Ian Lance Taylor wrote:

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

The change to have all STRING_CSTs NUL terminated (but that NUL
termination not necessarily inclided in STRING_LENGTH) is a good
one.

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.

Bernd?

Richard.

> Ian
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]