From 5751651251714810319 X-Google-Thread: f78e5,a3e3a55c5c3611c7 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!news4.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "James Kanze" Newsgroups: comp.std.c++ Subject: Re: atomically opening a file for writing that doesn't already exist? Date: Thu, 7 Dec 2006 09:40:17 CST Organization: http://groups.google.com Lines: 40 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1165490756.824987.320350@f1g2000cwa.googlegroups.com> References: <1165254139.347580.314450@l12g2000cwl.googlegroups.com> <1165427893.181335.149670@j44g2000cwa.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1165490772 2479 127.0.0.1 (7 Dec 2006 11:26:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 7 Dec 2006 11:26:12 +0000 (UTC) Return-Path: X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: f1g2000cwa.googlegroups.com; posting-host=62.160.54.162; posting-account=uN4QgA0AAAC_qk3WofNKjyjXNSBMXL2b X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-MIME-Autoconverted: from quoted-printable to 8bit by mulga.csse.unimelb.edu.au id kB7BQX9P012067 X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au Xref: g2news2.google.com comp.std.c++:4964 Greg Herlihy wrote: [...] > > There are however, features that are insecure in their very design. > > Except in very restricted cases, gets() is an invitation to code > > injection, and I hope everyone now knows to avoid using it. I would > > like to see mktemp() go the same way but as yet there is no alternative > > in the standard library. > The safer replacement for tmpnam(), tempfile() and related routines are > the mkstemp(), mkstemps(), mkdtemp() set of functions. None of which are standard. Not even if you consider Posix. The first is part of the Open Group common Unix specification. The other two, I've never even heard of---they aren't Posix, they aren't common Unix, and they aren't present on Solaris, or at least, if they are present, they are well hidden, since there's no man page for them, and the symbols aren't present in any file in /usr/include. In my own application code, portability to Solaris and Linux is all that counts (and some applications are only Solaris or only Linux), so I can freely use mkstemp (but not the other two) if it corresponds to my needs. Not all of my collegues have this liberty; the client stations are Windows on PC's. And I suspect that we're not the only company in the world using PC's under Windows. -- James Kanze (GABI Software) email:james.kanze@gmail.com Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34 --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]