Hi,

for a testsuite, I want to make sure that a program returns
a non-zero status in case of an error. This should be as
compiler-independent as possible, I am trying to avoid
run-time tests while testing different possibilities.
So, what can be tested?

Any reasonably modern compiler will have ERROR STOP, and
I expect that to set a non-zero condition code.

If that is not available, next I would try if the program

intrinsic abort
call abort
end

If that compiles, a call to abort should work at run-time.

I'm not sure that

stop 1
end

works in all cases, I would probably try that last.

Any others? Maybe read from an un-opened file? :-)

On Wed, 27 Jul 2022 19:55:03 +0000, Thomas Koenig wrote:

> Any others? Maybe read from an un-opened file? :-)

Modern compilers have a companion C processor.
abort() is part of the standard C library. The
prototype is "void abort(void)", so

interface
subroutine abort() bind(c, name="abort")
end subroutine
end interface

call abort

end

--
steve

On Wednesday, July 27, 2022 at 12:55:56 PM UTC-7, Thomas Koenig wrote:

> for a testsuite, I want to make sure that a program returns
> a non-zero status in case of an error. This should be as
> compiler-independent as possible, I am trying to avoid
> run-time tests while testing different possibilities.

(snip)

> I'm not sure that
>
> stop 1

As far as I know, all systems that have a return code, use the
number from STOP. I don't know that all OS have one, but
the usual ones do.

IBM tradition is to use return codes that are multiples of four.
Usual compiler return codes are 4 for warning, 8 for error, and
sometimes 12 for severe error.

Many years ago, I had a program that ends with STOP 8.

Running it on VMS, I believe VAX/VMS, as that was before Alpha,
VMS prints out the message in a table at position 8, which if I
find it right from a web search is "ACCVIO, Access Violation".

Took me a while to figure out that meant 8.

Hi Steve,

> On Wed, 27 Jul 2022 19:55:03 +0000, Thomas Koenig wrote:
>
>> Any others? Maybe read from an un-opened file? :-)
>
> Modern compilers have a companion C processor.
> abort() is part of the standard C library. The
> prototype is "void abort(void)", so
>
>
> interface
> subroutine abort() bind(c, name="abort")
> end subroutine
> end interface
>
> call abort
>
> end

You're right that this will produce a non-zero return code in
all cases. However, it might also produce a core dump (filling
up /var/crash on some Ubuntu systems, for example - not that I
agree with that design decision), which is not something I'd
like for a testsuite.

On 7/28/22 07:50, Thomas Koenig wrote:
>>
>> interface
>> subroutine abort() bind(c, name="abort")
>> end subroutine
>> end interface
>>
>> call abort
>>
>> end
>
> You're right that this will produce a non-zero return code in
> all cases. However, it might also produce a core dump (filling
> up /var/crash on some Ubuntu systems, for example - not that I
> agree with that design decision), which is not something I'd
> like for a testsuite.

$ ulimit -c 0
$ ./run_my_job

--
+------------------------------------------------------------------+
| https://framalibre.org/content/tetalab |
+------------------------------------------------------------------+

In article <eef02eea-cb4e-4e92-b1b3-b8bb27bb6163n@googlegroups.com>,
gah4 <gah4@u.washington.edu> writes:

> IBM tradition is to use return codes that are multiples of four.
> Usual compiler return codes are 4 for warning, 8 for error, and
> sometimes 12 for severe error.
>
> Many years ago, I had a program that ends with STOP 8.
>
> Running it on VMS, I believe VAX/VMS, as that was before Alpha,
> VMS prints out the message in a table at position 8, which if I
> find it right from a web search is "ACCVIO, Access Violation".
>
> Took me a while to figure out that meant 8.

Yes, the wonders of VMS:

$ exit 2928
%SYSTEM-W-FISH, my hovercraft is full of eels

On Thu, 28 Jul 2022 05:50:50 +0000, Thomas Koenig wrote:

> Hi Steve,
>
>> On Wed, 27 Jul 2022 19:55:03 +0000, Thomas Koenig wrote:
>>
>>> Any others? Maybe read from an un-opened file? :-)
>>
>> Modern compilers have a companion C processor.
>> abort() is part of the standard C library. The
>> prototype is "void abort(void)", so
>>
>>
>> interface
>> subroutine abort() bind(c, name="abort")
>> end subroutine
>> end interface
>>
>> call abort
>>
>> end
>
> You're right that this will produce a non-zero return code in
> all cases. However, it might also produce a core dump (filling
> up /var/crash on some Ubuntu systems, for example - not that I
> agree with that design decision), which is not something I'd
> like for a testsuite.

Yep, I thought about that after I posted. It should be possible
to use exit(3).

use iso_c_binding, only : c_int
interface
subroutine exit(n) bind(c, name="exit")
import c_int
integer(c_int), value :: n
end subroutine exit
end interface

--
steve

Phillip Helbig (undress to reply) <helbig@asclothestro.multivax.de> schrieb:
> In article <eef02eea-cb4e-4e92-b1b3-b8bb27bb6163n@googlegroups.com>,
> gah4 <gah4@u.washington.edu> writes:
>
>> IBM tradition is to use return codes that are multiples of four.
>> Usual compiler return codes are 4 for warning, 8 for error, and
>> sometimes 12 for severe error.
>>
>> Many years ago, I had a program that ends with STOP 8.
>>
>> Running it on VMS, I believe VAX/VMS, as that was before Alpha,
>> VMS prints out the message in a table at position 8, which if I
>> find it right from a web search is "ACCVIO, Access Violation".
>>
>> Took me a while to figure out that meant 8.
>
> Yes, the wonders of VMS:
>
> $ exit 2928
> %SYSTEM-W-FISH, my hovercraft is full of eels

Ah, the Hungarian phrasebook with intent to breach
the peace.

Any special meaning to 2928?

On Wednesday, July 27, 2022 at 12:55:56 PM UTC-7, Thomas Koenig wrote:
> Hi,
>
> for a testsuite, I want to make sure that a program returns
> a non-zero status in case of an error. This should be as
> compiler-independent as possible, I am trying to avoid
> run-time tests while testing different possibilities.

I haven't thought about this recently, but do all operating systems
(that are actually operating systems) have a return code?

IBM has had one at least since OS/360, where it is the low bits
of R15 when the program exits. I presume that DOS/360 and
its descendants also have one, and other later IBM OS.

Unix and unix-like system have one, usually set with the
C library exit() function, as noted. Are there any systems
with a Fortran compiler, but not a companion C compiler?

As noted VAX/VMS, and VMS descendants have one,
I am trying to remember other DEC OS, such as RT-11,
and TOPS-10.

I didn't use PC-DOS/MS-DOS back to 1.0, so I am not sure
about those. Definitely newer versions have one, and
Windows, too.

I don't know at all about others, like Primos for Prime,
RDOS for DataGeneral, or other non-Unix minicomputer
systems.

tTh <tth@none.invalid> schrieb:
> On 7/28/22 07:50, Thomas Koenig wrote:
>>>
>>> interface
>>> subroutine abort() bind(c, name="abort")
>>> end subroutine
>>> end interface
>>>
>>> call abort
>>>
>>> end
>>
>> You're right that this will produce a non-zero return code in
>> all cases. However, it might also produce a core dump (filling
>> up /var/crash on some Ubuntu systems, for example - not that I
>> agree with that design decision), which is not something I'd
>> like for a testsuite.
>
> $ ulimit -c 0
> $ ./run_my_job

Not so easy to integrate into an existing testsuite framework,
unfortunately.
>

On 7/27/2022 3:55 PM, Thomas Koenig wrote:
> Any reasonably modern compiler will have ERROR STOP, and
> I expect that to set a non-zero condition code.

Note that the standard recommends, but does not require, a compiler to
set the program exit status based on the STOP code. The words are:

"If the stop-code is an integer, it is recommended that the value be
used as the process exit status, if the processor supports that concept."

The only requirement is that " its stop code, if any, is made available
in a processor-dependent manner."
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Friday, July 29, 2022 at 8:45:30 AM UTC-7, Steve Lionel wrote:

(snip)
> Note that the standard recommends, but does not require, a compiler to
> set the program exit status based on the STOP code. The words are:
> "If the stop-code is an integer, it is recommended that the value be
> used as the process exit status, if the processor supports that concept."
> The only requirement is that " its stop code, if any, is made available
> in a processor-dependent manner."

As well as I know, it is not unusual to print out the value, if there is
a place to print it.

Some systems will print out the return code, or only print out
non-zero values, along with returning them where they go.

I was trying to think of any systems that don't have something like
a return code to return.

Do any systems have a return code, but don't allow one to use it?
That is for example, to do something conditional on the value?

On Saturday, July 30, 2022 at 9:07:48 AM UTC+12, gah4 wrote:
> On Friday, July 29, 2022 at 8:45:30 AM UTC-7, Steve Lionel wrote:
>
> (snip)
> > Note that the standard recommends, but does not require, a compiler to
> > set the program exit status based on the STOP code. The words are:
>
> > "If the stop-code is an integer, it is recommended that the value be
> > used as the process exit status, if the processor supports that concept."
>
> > The only requirement is that " its stop code, if any, is made available
> > in a processor-dependent manner."
> As well as I know, it is not unusual to print out the value, if there is
> a place to print it.
>
> Some systems will print out the return code, or only print out
> non-zero values, along with returning them where they go.
>
> I was trying to think of any systems that don't have something like
> a return code to return.
>
> Do any systems have a return code, but don't allow one to use it?
> That is for example, to do something conditional on the value?

Some years ago I had access to NAG Fortran and was surprised to find that if one's stop code was an integer it was written out in octal not decimal. I don't know if NAG still does that.

jfh <harperjf2@gmail.com> schrieb:
> On Saturday, July 30, 2022 at 9:07:48 AM UTC+12, gah4 wrote:
>> On Friday, July 29, 2022 at 8:45:30 AM UTC-7, Steve Lionel wrote:
>>
>> (snip)
>> > Note that the standard recommends, but does not require, a compiler to
>> > set the program exit status based on the STOP code. The words are:
>>
>> > "If the stop-code is an integer, it is recommended that the value be
>> > used as the process exit status, if the processor supports that concept."
>>
>> > The only requirement is that " its stop code, if any, is made available
>> > in a processor-dependent manner."
>> As well as I know, it is not unusual to print out the value, if there is
>> a place to print it.
>>
>> Some systems will print out the return code, or only print out
>> non-zero values, along with returning them where they go.
>>
>> I was trying to think of any systems that don't have something like
>> a return code to return.
>>
>> Do any systems have a return code, but don't allow one to use it?
>> That is for example, to do something conditional on the value?
>
> Some years ago I had access to NAG Fortran and was surprised to
> find that if one's stop code was an integer it was written out in
> octal not decimal. I don't know if NAG still does that.

Seems it does not:

$ cat stop.f90
stop 123
end
$ nagfor stop.f90
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101
[NAG Fortran Compiler normal termination]
$ ./a.out || echo $?
STOP: 123
123
$

On 7/29/2022 5:07 PM, gah4 wrote:
> As well as I know, it is not unusual to print out the value, if there is
> a place to print it.

This is why we added the QUIET= option to STOP and ERROR STOP.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org