Micah Cowan <[EMAIL PROTECTED]> writes: > Okay... but I don't see the logic of: > > 1. If the system has POSIX's sigsetjmp, use that. > 2. Otherwise, just assume it has the completely unportable, and not > even BSDish, siggetmask.
Are you sure siggetmask isn't BSD-ish? When I tested that code on various Unix systems, the only one without sigsetjmp was Ultrix, and it had siggetmask. Linux man page claims siggetmask to belong to the "BSD signal API" and the headers expose it when _BSD_SOURCE is defined. > AFAIK, _no_ system supports POSIX 100%, In case it's not obvious, I was trying to make the code portable to real Unix and Unix-like systems. So, the logic you don't see happened to cover both POSIX and all non-POSIX systems I laid my hands on, or heard of. Wget was ported to *very* strange systems, and I don't remember problems with run_with_timeout. > At least sigblock(0) is more portable, What makes you say that? > And saying that VMS should implement its own completely separate > run_with_timeout just I know nothing of VMS. If it's sufficiently different from Unix that it has wildly different alarm/signal facilities, or no alarm/signal at all (as is the case with Windows), then it certainly makes sense for Wget to provide a VMS-specific run_with_timeout and use it on VMS. Exactly as it's now done with Windows. > because it lacks an unportable facility doesn't make sense--esides > which, we're talking about a Unix here (Tru64), not VMS (yet). Do you say that Tru64 lacks both sigsetjmp and siggetmask? Are you sure about that?
