[PATCHv2] Handle overlength string literals in the fortan FE

[Bernd Edlinger]

On 09/05/18 20:16, Janne Blomqvist wrote:
> On Tue, Sep 4, 2018 at 10:05 AM Bernd Edlinger <bernd.edlinger@hotmail.de <mailto:bernd.edlinger@hotmail.de>> wrote:
> 
>     On 03/09/2018, 21:25 Janne Blomqvist wrote:
>      > On Fri, Aug 24, 2018 at 11:06 PM Bernd Edlinger <bernd.edlinger@hotmail.de <mailto:bernd.edlinger@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.
> 
> 
> I guess, I'm slightly confused why this mismatch happens in the first place (does the Fortran frontend do something dumb wrt string declarations, or?), but, Ok for trunk.
> 
> 

This is something that happens only on the test case that is mentioned in the comment.
If I remember correctly the string constant is 3 characters long, as well as the
type info on the STRING_CST itself, but the type of the object has only 2 byte
space for the string.  Therefore make the string shorter, and use the original type from
the declaration.

I am going to apply this together with the rest of the STRING_CST semantic patches,
once those are approved.


Thanks
Bernd.