The way to get around that is by sticking the actual string on the heap somewhere and only storing a pointer to it in the array. This isn't a unique problem to Fortran; it's how basically every programming language does it. The difference is that Fortan doesn't automatically heap allocate them for you - you've got to manually box them with a derived type - and that most other languages don't even give you the option of strings without pointer chasing.
I would argue that, while this characteristic is certainly going to seem weird to anyone who's used to a higher-level language, in a language like Fortran where the primary use case is high performance computing, putting the programmer in charge of these sorts of decisions is neither a bug nor a wart; it's a huge feature.
That said, I feel compelled to point out that one shouldn't judge Fortran as a whole by the need for a library like this in a 40 year old version of the language. I'm still learning the language, so I can't speak with a lot of authority, but it seems to me that, while Fortran is never going to be my favorite language for text munging, its string handling has come a long, long way between then and the Fortran 2018 standard.
Kind of like how there isn't a C# 2005 standard. That's a specific dialect of C# associated with a commercial compiler. The closest standard is the C# 4th edition ISO standard, which covers a subset of C# 2005's features. But it's still OK to refer to C# 2005 as a thing.
I think that this is a useful distinction to make in Fortran-land. I haven't used any of these old Fortran compilers, but my understanding is that they were all significantly different and more-or-less mutually incompatible. The Fortran standard had a minimal standard library, so things like what functions you had available for string manipulation depended more on the compiler you used.
I have used FORTRAN-80 quite a lot, before being able to use an IBM PC compatible computer.
An 8080 or Z80 was able to do only about 100 (@ 2 MHz) to 200 (@ 4 MHz) double-precision floating-point operations per second.
When I was able to use for the first-time a PC/AT with an 80386DX @ 25 MHz with coprocessor, which could do 100 thousand such operations per second, I recompiled an older FORTRAN-80 program and its run time dropped from 1 hour on CP/M to a few seconds on the PC/AT. Obviously I was very impressed.
Er... no. There is: it's just that C# stopped being published as an ISO Standard after version 2.0, and MS stopped publishing C# as an ECMA Standard a few years ago, but the C# language still has specifications and those specifications have version numbers - and those version numbers are used as compiler flags: `csc /langversion:7.3`, for example.
> But it's still OK to refer to C# 2005 as a thing.
"C# 2005" was C# 2.0, the last version with an ISO spec.
Currently we're on C# 9.0 in .NET 6. C# language spec versions and .NET releases are tied together as new language features have dependencies on BCL features (e.g. C# 8.0's `foreach-await` requires `IAsyncEnumerable` which was added in .NET Core 3: https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/...
That said, the C# language does enjoy relatively good evolution and progress that's almost as rapid as Swift's, and unlike, say, Java, which feels to me like it's progressing at half the speed of C#.
Notice that the first release of FORTRAN I is earlier than standardization of ASCII.
FORTRAN was initially born for IBM 704 then ported to huge variety of machine architectures. So there's no guarantee on internal string representation; It might be EBCDIC, ASCII, or other ancient, machine specific encodings.