Character format for integer type

[andrew_4619]

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

[cryptogram]

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.

[Steve_Lionel · Accepted solution]

In FORTRAN 66, this was how you had to do it since there was no CHARACTER data type. The Intel compiler still supports this. It is not standard now, but the compiler is not required to diagnose this (and it is tricky to do.)

[FortranFan]

Andrew,

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.

[Steve_Lionel]

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.)

[andrew_4619]

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.......

[Steve_Lionel]

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.