This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCHv2] Handle overlength string literals in the fortan FE
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Fortran List <fortran at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>, Tobias Burnus <burnus at net-b dot de>, Jeff Law <law at redhat dot com>
- Date: Tue, 4 Sep 2018 07:05:23 +0000
- Subject: Re: [PATCHv2] Handle overlength string literals in the fortan FE
- References: <AM5PR0701MB2657951582B419E5B2AFB48CE42D0@AM5PR0701MB2657.eurprd07.prod.outlook.com> <AM5PR0701MB2657FF3F97522D1476134A6DE4360@AM5PR0701MB2657.eurprd07.prod.outlook.com>,<CAO9iq9HFd0pkMj+gG5zn8E1Jo-ySseNHboSAzyLGg2Y9nyeEDw@mail.gmail.com>
On 03/09/2018, 21:25 Janne Blomqvist wrote:
> On Fri, Aug 24, 2018 at 11:06 PM Bernd Edlinger <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.