On 03/09/2018, 21:25 Janne Blomqvist wrote: > On Fri, Aug 24, 2018 at 11:06 PM Bernd Edlinger <bernd.edlin...@hotmail.de> > wrote: > >> Hi! >> >> >> This is an alternative approach to handle overlength strings in the >> Fortran FE. >> > > Hi, > > can you explain a little more what the problem that this patch tries to > solve is? What is an "overlength" string?
In the middle-end STRING_CST objects have a TYPE_DOMAIN which specifies how much memory the string constant uses, and what kind of characters the string constant consists of, and a TREE_STRING_LENGTH which specifies how many bytes the string value contains. Everything is fine, if both sizes agree, or the memory size is larger than the string length, in which case the string is simply padded with zero bytes to the full length. But things get unnecessarily complicated if the memory size is smaller than the string length. In this situation we have two different use cases of STRING_CST which have contradicting rules: For string literals and flexible arrays the memory size is ignored and the TREE_STRING_LENGTH is used to specify both the string length and the memory size. Fortran does not use those. For STRING_CST used in a CONSTRUCTOR of a string object the TREE_STRING_LENGTH is ignored, and only the part of the string value is used that fits into the memory size, the situation is similar to excess precision floating point values. Now it happens that the middle-end sees a STRING_CST with overlength and wants to know if the string constant is properly zero-terminated, and it is impossible to tell, since any nul byte at the end of the string value might be part of the ignored excess precision, but this depends on where the string constant actually came from. Therefore I started an effort to sanitize the STRING_CST via an assertion in the varasm.c where most of the string constants finally come along, and it triggered in two fortran test cases, and a few other languages of course. This is what this patch tries to fix. Bernd.
