From owner-cvs-all Thu Jul 26 9: 1:47 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 432CD37B405; Thu, 26 Jul 2001 09:01:39 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA09054; Fri, 27 Jul 2001 02:01:21 +1000 Date: Fri, 27 Jul 2001 01:58:02 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: Garrett Wollman , Kris Kennaway , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/sys sigaction.2 In-Reply-To: <200107251439.f6PEdro07401@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001, Warner Losh wrote: > In message Bruce Evans writes: > : > Are these functions officially signal-safe, or just signal-safe in our > : > particular implementation? > : > : Only in our implementation. It's hard to see how strcpy() could be > : signal-unsafe, but POSIX doesn't require it to be signal-safe. > > Strcpy isn't atomic. So if the source string changes in a signal > handler, unpredictable results will ensue. That doesn't make it signal-unsafe any more than the possibility of open(2)'s string arg changing makes open(2) signal-unsafe. open(2) _is_ one of the functions specified by POSIX to be signal-safe. Signal-safety has something to do with not having internal safe which might be corrupted by using the function in a signal handler or which might be in an inconsistent state when the function is called from a signal handler. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message