Hi Mikael!
Am 23.06.25 um 19:51 schrieb Mikael Morin:
Le 22/06/2025 à 21:09, Harald Anlauf a écrit :
Hi Mikael!
Am 20.06.25 um 12:08 schrieb Mikael Morin:
From: Mikael Morin <mik...@gcc.gnu.org>
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the type. This can produce confusing dumps with code having multiple
SELECT TYPE statements, as it isn't obvious which SELECT TYPE construct
the variable relates to. This is especially the case with nested SELECT
TYPE statements and with SELECT TYPE variables having identical types
(and thus identical names).
This change adds one additional user-provided discriminating string in
the variable names, using the value from the SELECT TYPE variable name
or last component reference name.
The idea makes a lot of sense.
It's a purely convenience change, not a correctness issue.
While this is true, one needs to check whether all buffers used
to hold the new, longer artificial symbol name are big enough.
Skimming over the patch, I have the impression that at least
the following temporaries need to be check and likely adjusted.
Thanks for the review. Very good point indeed.
So we have a constant, GFC_MAX_SYMBOL_LEN, bounding the size of the
symbol name that a user is permitted to choose, making it possible to
use static buffers based on that upper limit.
But then there are internal/artificial symbols using names that are
built around the user-provided names, thus permitted to exceed
GFC_MAX_SYMBOL_LEN by a few units.
This is a known problem.
There was a recent discussion to increase this limit, see also pr117381.
It is not trivial to fix this (although it might be "straightforward").
So in the end, I'm not sure that the various static buffers we have all
around are safe in the face of these artificial symbols. And what is
the actual true bound on symbol names. For what's worth gfc_get_string
uses a buffer of size 3*GFC_MAX_SYMBOL_LEN + 21.
Back to the patch, I've added a truncation to the buffers which I
haven't extended (except for one spot, see below). At least the
situation shouldn't be any worse than before.
Very long identifiers are fortunately sufficiently rare, but some
people tend to test the limits...
Regression-tested on x86_64-pc-linux-gnu. I also checked the testcase
manually with valgrind.
Good.
Ok for master?
Yes, OK for master.
Thanks for the patch!
Harald
