- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
istat=-99 ! initialise istat as it might not be assigned and then gives an uninitalised var failure. CALL EXECUTE_COMMAND_LINE("fred.exe",WAIT=.true.,EXITSTAT=istat)
And from the help>>>
exitstat |
(Inout; optional) Must be a scalar of type integer. If the command is executed synchronously, exitstat is assigned the value of the processor-dependent exit status of the executed command. Otherwise, the value of exitstat is unchanged. |
If istat is not pre-initialised and if a synchronous command fails to run (e.g. not found) istat is returned uninitialised and a "check uninit" runtime error occurs. I can see a number of different argument on this but the normal expectation of a intrinsic with a return status is for the return status to always be set.
I think a note advising initialisation by be helpful as setting a return status that is unconnected with the command being run might also cause confusion.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
app4619 wrote:
If istat is not pre-initialised and if a synchronous command fails to run (e.g. not found) istat is returned uninitialised and a "check uninit" runtime error occurs. I can see a number of different argument on this but the normal expectation of a intrinsic with a return status is for the return status to always be set.
Given your specific example code - does it matter? No statements following the failed intrinsic call will be executed.
The same "not defined unless some other condition applies" behaviour applies in a few other places in the standard language - IOMSG specifiers (CMDMSG) is similar) for example.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The standard is quite explicit as to the required behavior:
"EXITSTAT (optional) shall be a default integer scalar. It is an INTENT (INOUT) argument. If the command is
executed synchronously, it is assigned the value of the processor-dependent exit status. Otherwise,
the value of EXITSTAT is unchanged"
This is not a "return status" - it is the exit status of the executed synchronous command. If there was no such thing, then what would you have the exit status set to? You want to also specify CMDSTAT and check that first.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the case where istat=-99 is pre-set and then we make the call, and fred.exe does not exist istat=1 is returned and the program goes on it merry way having done nothing. In the case where istat is not pre-set the program crashes.
That does not seem to great behaviour, it is not a problem after you have got is wrong once you are then prepared for next time..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You want to also specify CMDSTAT in the case that the command cannot be executed. I would not rely on uninitialized variable detection here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I should add that I was not interested in the exit status and the application did not check or reference it because it is externally obvious in this case if the external command ran or not and if it was successful or not.
Surely an initialised variable is only a problem if you touch it? I guess in my case EXECUTE_COMMAND_LINE tries to do something with the value passed in prior to it being assigned a new value.
It is also seems clear now that in this case I should not have asked for an exitstatus, force of habit from normal i/o command that otherwise crash on error made me do this.....
And finally...
Actually it does say in the help having read is more carefully that it is intent(inout) so perhaps I should have noted that....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, I see what you're getting at. Because of the semantics of this routine, the fact that we want it to work with all integer/logical sizes AND properly work with /fpscomp:logicals, the compiled code does some work before and after the call. I'll take a closer look at this and see if we can at least avoid the uninitialized check here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A very minor point just noted in 2015 documentation:
Green "Indicates Intel extensions (non-standard features) that may or may not be implemented by other compilers. Features defined by the Fortran 2008 Standard or the OpenMP 4.0 API are shown in black."
And under OPEN we have (in green) :
var |
Returns automatically chosen, unused, unit number |
No default |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks - I'll let the writers know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The uninitialized error has been escalated as issue DPD200365558.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This should get fixed in 16.0.1 (2016 Update 1).

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page