From: <chr...@ma...> - 2020-05-27 19:36:04
|
On 2020-05-27 00:47, Branden Archer wrote: > (I do not seem to be getting all the emails from Ken for some reason. I > see some message I did not see in Fredrik's response.) My emails from Ken say "Ken Moffat via Check-devel", if there's an issue it's probably related to that. I'll forward them all in order. Ken, please reply-all if you aren't already, the mailing list won't send duplicate messages. > Perhaps the test needs to be updated to pick another signal to try. Or, > maybe inducing a division by zero is a portable way to cause a SIGFPE. Since Check is a C unit testing framework, we could assume that tested systems are compliant either with ISO C or a well-defined subset of ISO C, e.g. ISO C without forking. The POSIX-2017 spec refers to ISO C and is clear that raise(SIGFPE) is supposed to generate a signal: The ISO C standard only requires the signal names SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM to be defined. An implementation need not generate any of these six signals, except as a result of explicit use of interfaces that generate signals, such as raise(), [CX] [Option Start] kill(), the General Terminal Interface (see Special Characters), and the kill utility, unless otherwise stated (see, for example, XSH Memory Protection). https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html The C11 standard has the similar wording on page 283 (numbered as 265): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf I'm not an expert in this area by any means. I'm most curious to know if Ken's observed behaviour is a bug or if his system is working as intended, and if so then why? Probably someone at gcc/clang/glibc/linux will know a lot more about this. Chris |