This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Make GO string literals properly NUL terminated
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Richard Biener <rguenther at suse dot de>, Ian Lance Taylor <iant at golang dot org>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 1 Aug 2018 07:44:42 +0000
- 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>,<alpine.LSU.email@example.com>
> 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.
The advantage is that there are less variations how string literals look
like in the middle end. We will have a simple way to determine if
a string literal is NUL terminated or not. And checking that property
in varasm.c is exactly the right thing to do.
String literals always have an array_type which may be shorter
than TREE_STRING_LENGTH, but that chops off only exactly
one wide character nul. Otherwise if the array_type is equal or larger,
we know for sure the value is nul terminated. In the middle-end
we can easily determine if a string is not NUL terminated by:
compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)),
TREE_STRING_LENGTH (init)) < 0
I did use that already in my patch for pr86711.
Additionally not having oversize string constants produced
by the front ends, where the extra characters are good for nothing,
also helps to improve correctness.