[PATCH] Make GO string literals properly NUL terminated

Bernd Edlinger bernd.edlinger@hotmail.de
Wed Aug 1 13:05:00 GMT 2018



On 08/01/18 11:29, Richard Biener wrote:
> 
> Hmm.  I think it would be nice if TREE_STRING_LENGTH would
> match char[2] and TYPE_SIZE_UNIT even if that is inconvenient
> for your check above.  Because the '\0' doesn't belong to the
> string.  Then build_string internally appends a '\0' outside
> of TREE_STRING_LENGTH.
> 

Hmm. Yes, but the outside-0 byte is just one byte, not a wide
character.  There are STRING_CSTs which are not string literals,
for instance attribute tags, Pragmas, asm constrants, etc.
They use the '\0' outside, and have probably no TREE_TYPE.

> 
>> So I would like to be able to assume that the STRING_CST objects
>> are internally always generated properly by the front end.
> 
> Yeah, I guess we need to define what "properly" is ;)
> 
Yes.

>> And that the ARRAY_TYPE of the string literal either has the
>> same length than the TREE_STRING_LENGTH or if it is shorter,
>> this is always exactly one (wide) character size less than TREE_STRING_LENGTH
> 
> I think it should be always the same...
> 

One could not differentiate between "\0" without zero-termination
and "" with zero-termination, theoretically.
We also have char x[100] = "ab";
that is TREE_STRING_LENGTH=3, and TYPE_SIZE_UNIT(TREE_TYPE(x)) = 100.
Of course one could create it with a TREE_STRING_LENGTH = 100,
but imagine char x[100000000000] = "ab"

>> The idea is to use this property of string literals where needed,
>> and check rigorously in varasm.c.
>>
>> Does that make sense?
> 
> So if it is not the same then the excess character needs to be
> a (wide) NUL in your model?  ISTR your varasm.c patch didn't verify
> that.
> 

I think it does.


Bernd.


More information about the Gcc-patches mailing list