(j3.2006) when does an error condition occur in executing EXECUTE_COMMAND_LINE

Bill Long longb
Fri Jan 16 14:25:13 EST 2009

Michael Ingrassia wrote:
>> My inclination is to intentionally 
>> not specify what errors can or cannot be detected.
> Ok, but we can and should add value to the standard by making it possible
> for as many errors as possible to be error conditions, right?
> The distinction is that once an error occurs, all bets are off and the
> program can do anything; but the standard can prescribe what happens
> for error conditions (e.g., you lose the guarantee that something actually
> got allocated but if you set the STAT variable then execution does not
> terminate, etc.)
> Say you call EXECUTE_COMMAND_LINE and the command doesn't execute.
> The standard says it does, so you're in error territory and nothing else
> about your program execution is guaranteed by the standard.   But if
> command not executing is an error condition, maybe CMDSTAT or EXITSTAT
> could be set and the program and processor could still be standard-conforming.
> I thought that's what we wanted, and if so I still think 
> some of the language in the standard is not quite right.   
> The standard shouldn't say "a command will be executed" -- that makes it an
> error if a command isn't executed whereas some OS's can do better (can detect
> some errors).
> The standard should say "unless an error condition occurs, a command will
> be executed" -- that permits (but does not require) an error condition to
> be detected if a command isn't executed.  

I think that is what is implied.  In many places in the standard, we say 
'statement X does Y' when we really mean it does Y assuming no error 
occurs.  For example, see the first line of the OPEN statement 
description at 09-007[208:9].  Similar for the other I/O statements.  
Even the description of simple assignment assumes you don't hit a segfault.

> And we could also say "which errors, if any, are detected is processor 
> dependent".

This seems OK.  It makes the point that the standard does not have a 
list of the errors and error code values somewhere, so the user would 
not bother looking.


> 	--Michael I.
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120


More information about the J3 mailing list