I had a code bug where format and types were defined in a external configuration file and interpreted at run time. A string was filled with "garbage" which caused problems later on. The short sample below summarises the error. I was surprised that writing integer using the character '(A)' format is not an error. Is that some historical throw back from the Holleriths and all that old time stuff ?
program fmt_test_20200915 implicit none (external) integer :: num, istat character(20) :: fred, gfmt fred = '' gfmt = '(A)' num = 9999 WRITE( fred, GFMT, iostat = istat ) Num print *, istat print *, fred end program fmt_test_20200915
Memory gets fuzzy after 45 years, but I seem to remember that the Fortran II compiler on the IBM 1620 allowed something like this. And I definitely remember doing this sort of thing on the IBM mainframe using the G series compilers. Early versions of Fortran didn't have character types, so doing this sort of thing was a workaround. I remember storing reservoir names in two real*8 arrays, with the first 8 characters of the name in the first array, and the rest of the name in the 2nd.
Perhaps you will consider filing a support request with Intel to see if they will add an item to their longer term to-do list to issue a diagnostic warning for this, at least when /stand compiler option is in effect.
I seem to recall a team I consulted with a while ago where I work who took my advice and used different approach to FORMAT statements for WRITEs vs READs. Note their read's were rather limited, mostly contained in a couple of subroutines in one module whereas they had write's all over the place. And the approach was to use the "generic" option for output i.e., the G format specification. Type-specific format editing such as 'I', or 'F', or 'A' were only used for READs. Not sure if this will be an option for you.
This would have to be a run-time diagnostic. It's certainly feasible but would require revising the interface between compiler and run-time library. There are a lot of other non-standard behaviors that could be diagnosed this way, but I have seen deluges of complaints from users any time a run-time diagnostic is added (even when they're optional.)
I opened the topic as I wanted some other views on this and to know if it was a compiler 'problem'. I suspected it was historical and now non-standard baggage which it seems that it is. Thank you all for replying.
For my case I thought all possibilities had been validated however the format string could validly have integer or character type dependant on other flags that could be set. I added some additional data validation so I don't specifically have a problem now.
The run time case is debatable but the case where the format is known at compile time should give a standards error IMO. On the other hand there are plenty of other things I would rather the compiler teams was working on.......
Evcen for cases where the format is known at compile-time, the compiler would have to try to match values in the I/O list with formats, and much of this behavior isn't known until run-time. If it were to be done at all, it would have to be in the run-time format processing when it knows for sure what the type is.