Date: Wed, 14 Jun 2000 12:17:07 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Alain Magloire cc: djgpp-workers AT delorie DOT com Subject: Re: tmpfile in DJGPP In-Reply-To: <200006131530.LAA10059@qnx.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 13 Jun 2000, Alain Magloire wrote: > There are good reasons not to use tmpfile(); because of security risks: Then let's invent a new function with tmpfile's semantics, but better security, or enhance tmpfile with extensions that solve these problems. But to write programs which _rely_ on the OS to defer removal of files until the last app closes them is IMHO terribly non-portable to any platform except the one that supports this. FWIW, I'm quite sure that many programs which use this trick, at least those I've seen, couldn't care less about security, since they use mktemp to create the file names, and mktemp has its own security problems and race condition risks. If the GNU project wants to increase its popularity and to draw more people to Free Software, IMHO it's high time to stop assuming that Posix platforms are the only ones that matter. Experience shows that this is both bad philosophy and bad economics. For example, if the FSF would realize that DJGPP's popularity is a Good Thing, as DJ tried to lobby them for years, they would be gathering lots of money from selling CD-ROMs with DJGPP-based ports for many years, instead of starting just a year ago, and many more DOS/Windows users would be exposed to the benefits of Free Software, albeit on a proprietary platform.