To shield programs that call abidiff against runs that could possibly take too much time, a --timeout option would be appropriate. That option would take an argument N in seconds. If abidiff does not complete before N seconds, its execution would be aborted and a message would be emitted on the standard error output, saying that the execution has been aborted because it could not be performed within N seconds. One possible way to implement this could be by using a combination of fork, exec, waitpid, alarm an kill system calls.
What return code will be returned. Non-zero would be a choice. The test results by the part of check that is already done still outputs. I think it would make sense.
I'd like this for abidw as well, so that for my build system usage, if abidw takes too long, I can bail out and do a normal content signature, rather than the ABI based one.
Some people have proposed that we just use the program 'timeout', provided by coreutils, for this use case. The reason why I was thinking about having a --timeout option was to have a finer control about what we return in that case. Right now, the 8 bits exit value of abidiff tells us about the kind of difference or error encountered. In case of timeout error (and if abidiff handles --abidiff), we could flip the first bit (which mean there was an error) and then flip the third bit too, saying that there was a timeout. Otherwise, if users use the "timeout" program from coreutils, handling the exit code gracefully seems a little bit more bumpy. What do you think?
OK, finally, I think that just using the "timeout" program from coreutils is a better solution. I don't really see a compelling reason for not using that one.