Any others? Maybe read from an un-opened file? :-)
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'm not sure that
stop 1
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
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.
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.
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
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.
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
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."
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 availableAs well as I know, it is not unusual to print out the value, if there is
in a processor-dependent manner."
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 toAs well as I know, it is not unusual to print out the value, if there is
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."
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.
As well as I know, it is not unusual to print out the value, if there is
a place to print it.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 98:42:33 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,783 |