https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #8 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #6)
> This begs the question whether we should support longer symbols as an
> extension.
This likely would require a big change to the frontend. There are
145 static buffers that use GFC_SYMBOL_LEN. These would need to be
replaced by either dynamic memory allocation or static buffers that
waste memory.
% grep SYMBOL_LEN *cc | grep char | wc -l
145
...
trans-types.cc: char name[8 + 2*GFC_RANK_DIGITS + 1 + GFC_MAX_SYMBOL_LEN];
trans-types.cc: char caf_name[GFC_MAX_SYMBOL_LEN + 6];
trans-types.cc: char name[GFC_MAX_SYMBOL_LEN + 1];
trans-types.cc: char name[GFC_MAX_SYMBOL_LEN + 1];
One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
value makes sense? (Note it will be less than 10000, which is the
longest statement length allowed under the standard)
