On 12/08/2017 02:36 PM, 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). POSIX says that SIGABRT is 6 on XSI systems, but you can be compliant with POSIX without being an XSI system (but non-XSI systems tend to not run autoconf). However, your bigger problem is that on ksh, SIGABRT shows up in $? as 262 (it specifically treats signals as 256+num instead of 128+num, to make signals unambiguous with normal exit status). > > The following options come to mind: > > * use `trap` in AT_CHECK to catch the error if it is the expected result > --> should fix the additional stderr, we still would have to check for > return code 134 Your trap could then exit (normally) with a known exit status, rather than reusing the inherited status that may or may not be 134. Or even write to a witness file, ignore the value of $? altogether, and do a second AT_CHECK that the witness file was touched. > Do you have any experience/thoughts about this? > Is there any "best practice" (ideally as official documentation) for > checking signals in the autoconf generated testsuite script? Expecting death to a signal is unusual, so I don't know of anyone else doing it. But if it is a common enough paradigm, I agree that making it easier in autotest to check that a process died due to a particular signal may be a worthwhile enhancement. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
