Re: How to check for SIGABRT?

[Bob Friesenhahn]

On Fri, 8 Dec 2017, Simon Sobisch wrote:

> We use the autoconf generated testsuite script in GnuCOBOL to test the
> compiler and runtime - and it works very well for "normal" tests.
>
> There are some tests where the compiler should abort and it does, but
> when it does so "correctly" by raising SIGABRT we can check for return
> code 134 but get an additional stderr message similar to
> "/full/path/to/testsuite.de/testcasenumber/run aborted on line 40" (and
> I don't know if SIGABRT will result in return code 134 on all "exotic"
> systems).

Different shells and different OSs will return a different code. 
There is no standard.

One thing you can do is to interject a tiny shim program which does 
fork/exec to start the program being tested and then use wait(2) or 
waitpid(2) to wait for the program to quit.  You can also just use 
system(3).  You can then use macros such as WTERMSIG() to see what 
signal caused the program to exit (if any).  You shim program can 
return codes that you expect.

The Linux manual page for waitid(2) documents the various macros and 
how to use them.

Some systems interject their own core file handling and may put core 
files in a special directory, use unexpected names for the core files, 
or say "Your system has a problem".  Producing core files in configure 
scripts may be confusing for the user.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/