Can IOMSG= keyword in I/O operations now accept an ALLOCATABLE character variable?

[FortranFan]

Haven't had a chance to try this out, but can IOMSG= keyword in I/O operations now accept an ALLOCATABLE character variable?  That is, is the following code compliant with the latest Fortran standard?

[fortran]

    CHARACTER(LEN=:), ALLOCATABLE :: ErrorMessage

    ...

    OPEN(NEWUNIT=UnitNum, FILE=SomeFile, IOMSG=ErrorMessage, IOSTAT=ErrorCode)

[/fortran]

It is unclear from the User and Reference Guide for the Intel® Fortran Compiler 14.0:

[plain]

I/O Message Specifier (IOMSG=)

The I/O message specifier designates a variable to contain the message to be returned when an I/O error occurs. It takes the following form:

IOMSG=msg-var

msg-var

Is a scalar default character variable.

If an error (ERR=), end-of-file (END=), or end-of-record (EOR=) condition occurs during execution of an I/O statement,msg-varis assigned an explanatory message.

If no error occurs, the value of the variable remains unchanged.

[/plain]

Thanks,

[IanH]

There was a discussion on c.l.f that touched on this recently.  The variable can [of course] be allocatable, but not in the way you want - you need to have allocated it to some length prior to the call (i.e. the IO statement won't change the allocation status or length or whatever).

So you need to guess how long any error message might be ahead of time.

Or use PL/I, apparently...

[FortranFan]

Thanks Ian.  Interesting discussion at c.l.f.  I can better appreciate the underlying complexity, especially in relation to backward compatibility.

Steve/Intel writers, does it make sense to update the documentation to include a comment or two on the allocation requirements of character arguments in procedures e.g. IOMSG?  I ask because the compiler doesn't give any error message if a allocatable string is not allocated to a fixed length prior to the procedure call.  One only gets an exception at run-time.

Regards,

[Steven_L_Intel1]

It isn't just IOMSG - it's only on intrinsic assignment where the (re)allocation happens. We'd have to add such a disclaimer to dozens if not hundreds of places throughout the documentation.

You should assume that prior allocation is required unless you're using intrinsic assignment.