From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.user Subject: Re: request tmpfile(3) wrapping in Guile 1.9 libguile Date: Mon, 8 Feb 2010 10:34:39 -0500 Message-ID: References: <877hqoubkv.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1265643356 24497 80.91.229.12 (8 Feb 2010 15:35:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Feb 2010 15:35:56 +0000 (UTC) Cc: guile-user@gnu.org, Thien-Thi Nguyen To: Andy Wingo Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Feb 08 16:35:53 2010 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NeVeM-0001ih-RS for guile-user@m.gmane.org; Mon, 08 Feb 2010 16:35:47 +0100 Original-Received: from localhost ([127.0.0.1]:39291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeVeM-00079k-8z for guile-user@m.gmane.org; Mon, 08 Feb 2010 10:35:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NeVdX-00073W-Ql for guile-user@gnu.org; Mon, 08 Feb 2010 10:34:55 -0500 Original-Received: from [140.186.70.92] (port=40917 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeVdV-00072w-Vx for guile-user@gnu.org; Mon, 08 Feb 2010 10:34:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NeVdV-0007et-AV for guile-user@gnu.org; Mon, 08 Feb 2010 10:34:53 -0500 Original-Received: from splat.raeburn.org ([69.25.196.39]:58875 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NeVdJ-0007e3-Vl for guile-user@gnu.org; Mon, 08 Feb 2010 10:34:53 -0500 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o18FYdiY010030; Mon, 8 Feb 2010 10:34:39 -0500 (EST) In-Reply-To: X-Mailer: Apple Mail (2.1077) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:7626 Archived-At: On Feb 8, 2010, at 06:11, Andy Wingo wrote: > 1. tmpfile(3) returns a FILE*, whereas Guile's fports normally deal in > file descriptors. Will this be a problem? What about buffering? Do we > have to fclose() the FILE* to get deletion working? On POSIX systems you can use fileno(). The automatic deletion is = probably handled by unlinking the file before returning the file handle. = But you probably can't get rid of the FILE* without calling fclose(), = which would throw away the file and file descriptor. On most UNIX = systems you could probably dup() the file descriptor indicated by = fileno() and then fclose() the FILE* handle, without losing the on-disk = temporary file storage. I don't know if you can use fileno on Windows. It's also not clear to = me from a quick look at the MSDN docs on tmpfile() whether the temporary = file gets deleted if your program changes directories while running. > 2. Why return 'tmpfile as the name, and not whatever filename one can > get from the FILE* ? If the file has been unlinked, the file name isn't going to be useful. = In fact, the tmpfile() interface doesn't give you a filename. > 3. Is tmpfile(3) really needed, if you have mkstemp! and dynamic > extents? Here's what I use, for example: But mkstemp doesn't guarantee that no one else will grab the file name = in between the time mkstemp checks that the file doesn't exist, and when = you actually open(O_CREAT) it. Using it can leave you with a race = condition such that you need to loop generating and then trying = filenames; tmpfile hides that away from the implementation, at least, or = maybe uses more randomness in its filenames than mkstemp supports. (And = if you don't use O_EXCL, you may have a security problem, too.) > (unwind-protect > (proc template) > (delete-file template)))) Interesting... A temp-file port type could probably be created that = either uses tmpfile or unlinks on close or destruction of the port = object, couldn't it? I don't know if that would be better or worse than = using tmpfile directly. Does the unwind-protect here catch any cases = that that would miss? Ken=