https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #12 from kargls at comcast dot net --- (In reply to anlauf from comment #11) > (In reply to kargls from comment #10) > > (In reply to anlauf from comment #9) > > > (In reply to kargls from comment #8) > > > > 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) > > > > > > You sure? > > > > > > F2023: 6.3.2.1 ... A line shall contain at most ten thousand characters. > > > > > > But can't you break a line like in: > > > > > > a& > > > &b& > > > &c = 1 > > > > > > ? > > > > Ugh, indeed, you are correct! I forgot that one could split > > a token across a line. The question still remains. What > > value does one use; especially given the 145 static buffers? > > I am not sure. We could use 255 as a hard limit, and emit a warning for any > -std=fxyz option when the respective limit is exceeded, at least for > -pedantic. For comparison sake, C23 5.2.4.1 has The implementation shall be able to translate and execute a program that uses but does not exceed the following limitations for these constructs and entities17): ... -- 63 significant initial characters in an internal identifier or a macro name (each universal character name or extended source character is considered a single character) -- 31 significant initial characters in an external identifier (each universal character name specify- There is a footnote that points to 6.11.3 "Future language directions" 6.11.3 External names Restriction of the significance of an external name to fewer than 255 characters (considering each universal character name or extended source character as a single character) is an obsolescent feature that is a concession to existing implementations. So, it seems that C is looking to relax limits to 255 characters.
