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.
