Nelson's point is that signal handlers are process-wide properties, and it is inappropriate for a library to change a process-wide property.
But I agree that SIGPIPE is an exception. This is why NSPR (a depenency of NSS) calls sigaction() to ignore SIGPIPE during initialization. Note that this is done for self protection, rather than as a documented service to the NSPR client. So the issue is why you receive SIGPIPE while calling NSSSSL_VersionCheck (). This implies that NSPR hasn't been initialized at that point. NSPR is implicitly initialized by the first NSPR function call that requires NSPR to be initialized. NSSSSL_VersionCheck is a trivial function and doesn't require NSPR to be initialized, so NSSSSL_VersionCheck doesn't cause NSPR to be initialized. If NSSSSL_VersionCheck is the very first NSPR/NSS call made by the application, NSPR won't be initialized at that point. If your app want to depend on NSPR's undocumented sigaction call for SIGPIPE, you can call PR_Init before calling NSSSSL_VersionCheck: https://developer.mozilla.org/en/PR_Init Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
