Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.unix.programmer Subject: Re: List of routines safe to use in signals? Message-ID: <1990Dec12.050527.2152@athena.mit.edu> Date: 12 Dec 90 05:05:27 GMT References: <1960@necisa.ho.necisa.oz> <59190@brunix.UUCP> Sender: news@athena.mit.edu (News system) Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Organization: Massachusetts Institute of Technology Lines: 27 In article <59190@brunix.UUCP>, cgy@cs.brown.edu (Curtis Yarvin) writes: |> Hey, excuse me if I'm being a complete newbie. But how can a reentrant |> library routine, say "strcpy", cause problems in this case? The obvious answer is, "How do you *know* the routine is reentrant?" Now, in response to that, you can say, "Why would anyone have any reason to write a strcpy function that isn't reentrant?" but that question misses the point. You can't assume anything about library functions that isn't in the spec for the function. If the man page (or, more recently, the ANSI spec, or the POSIX spec, or whatever) for the function says that it's reentrant, then it is, and you can count on it being reentrant. However, if that is not specified, then you cannot make any assumptions about whether or not the function is reentrant. Obviously, a signal handler that calls strcpy isn't going to have any trouble on the vast majority of systems currently in existence, if not on all systems. But there's no way to know that for sure. Furthermore, there's the "slippery slope" problem which says that if you first assume that strcpy is reentrant, you may continue to make that assumption with more and more functions, until suddenly you'll find yourself calling printf :-). -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710