220 5328 <8687c067-2ff2-4fcd-a9f6-3b896d4c0d12@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Remove filesystem unique_path Date: Sun, 7 Jul 2013 16:40:54 -0700 (PDT) Lines: 117 Approved: news@gmane.org Message-ID: <8687c067-2ff2-4fcd-a9f6-3b896d4c0d12@isocpp.org> References: <4b95e9b9-d5cc-4314-bd32-1e09fe35ed9d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1119_32375900.1373240454621" X-Trace: ger.gmane.org 1373240455 4908 80.91.229.3 (7 Jul 2013 23:40:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jul 2013 23:40:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMKHJ4B6MARBB7Z46HAKGQEDVCKGXI@isocpp.org Mon Jul 08 01:40:57 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f70.google.com ([209.85.212.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UvyZc-0000sL-LG for gclcip-std-proposals@m.gmane.org; Mon, 08 Jul 2013 01:40:56 +0200 Original-Received: by mail-vb0-f70.google.com with SMTP id q12sf4951318vbe.5 for ; Sun, 07 Jul 2013 16:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=MPfgx+Ix8WOliZCe/bpScOF3XFjDIvahHXWSfWirTNY=; b=vbtkikBkSSJjgBIflJSIBeaWPEmFwW5gOpBiTJhzVhKsEBzb+x/6j+LkF3VwK0elmL +e+kiNgj9KvxzuLvkFbbr/jAt+orBn0t+0nWvXKDmeUZz19dpgtci2Pn0i39viKrOZsT XqoBvHyEk44AQ4EECpf8AhORWqpVoQc+X1wyF0bXuoUUeeAm6QeAz+Bj6AJDf944b7Vy Ok/nHJGJUoGCn9Q8GLoEiaeDa+NcamLxdY5hCNAv0VMgUAbsfbTvQooeF/WxcDibQGtM dXFuc9PEFkc0xy508HAevJEmP3wYwxMemgNYLdB9ZMPvHqMee3c1nDx7VdInfpPEvpOf sIdg== X-Received: by 10.224.55.200 with SMTP id v8mr22402426qag.7.1373240455711; Sun, 07 Jul 2013 16:40:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.35.50 with SMTP id e18ls1699868qej.99.gmail; Sun, 07 Jul 2013 16:40:55 -0700 (PDT) X-Received: by 10.49.120.67 with SMTP id la3mr427016qeb.35.1373240455027; Sun, 07 Jul 2013 16:40:55 -0700 (PDT) In-Reply-To: <4b95e9b9-d5cc-4314-bd32-1e09fe35ed9d@isocpp.org> X-Original-Sender: lrdxgm@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5328 Archived-At: ------=_Part_1119_32375900.1373240454621 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 2013. j=FAlius 7., vas=E1rnap 12:59:11 UTC+2 id=F5pontban ma...@lysator.liu= ..se a=20 k=F6vetkez=F5t =EDrta: > > I was surprised when I looked at the file system proposal and found=20 > unique_path. > > unique_path is similar to the POSIX tempnam[1] function that was marked a= s=20 > obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstemp recommended in= =20 > it's place. Why incorporate the mistakes from posix in C++? > > The problem with unique_path is that there is a window of opportunity=20 > between the check that the path name is unique and the time when it is us= ed. > That window can be used by malware -- and in the case of tempnam it have= =20 > been used by malware. > > I thus propose that 15.38 is removed. > > /MF > Unlike tmpnam, what is part of C's (thus, part of C++'s = =20 as well), unique_path does not check the filesystem for existence of the=20 file (at least that's how I understand the comment about randomness); it=20 just generates a random string based on a template. One can argue that this= =20 simple functionality is not affected by the error: the existence check is= =20 delayed to creation. However, you are right that a temp file name can be used for nothing else= =20 than.. creating a temp file with that name, so this function is useless=20 alone. Thus I think it would be better if there would be a create_temp_file= =20 function that gets the same parameters, creates the appropriate temporary= =20 file and returns an fstream to it.. The function is useful for generating random strings based on a template=20 (like, generating a UUID), but it's quite awkward to have such=20 functionality in a filesystem library.. Regards, Robert --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_1119_32375900.1373240454621 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

2013. j=FAlius 7., vas=E1rnap 12:59:11 UTC+2 id=F5pontban ma...@lys= ator.liu.se a k=F6vetkez=F5t =EDrta:
I was surprised when I looked at the file system proposal and found u= nique_path.

unique_path is similar to the POSIX tempnam[1] function = that was marked as obsolecent in POSIX 2008 and tmpfile, mkdtemp and mkstem= p recommended in it's place. Why incorporate the mistakes from posix in C++= ?

The problem with unique_path is that there is a window of opportun= ity between the check that the path name is unique and the time when it is = used.
That window can be used by malware -- and in the case of tempnam i= t have been used by malware.

I thus propose that 15.38 is removed.
/MF

Unlike tmpnam, what is part of C's <s= tdio.h> (thus, part of C++'s <cstdio> as well), unique_path does n= ot check the filesystem for existence of the file (at least that's how I un= derstand the comment about randomness); it just generates a random string b= ased on a template. One can argue that this simple functionality is not aff= ected by the error: the existence check is delayed to creation.

Howe= ver, you are right that a temp file name can be used for nothing else than.= .. creating a temp file with that name, so this function is useless alone. T= hus I think it would be better if there would be a create_temp_file functio= n that gets the same parameters, creates the appropriate temporary file and= returns an fstream to it..

The function is useful for generating ra= ndom strings based on a template (like, generating a UUID), but it's quite = awkward to have such functionality in a filesystem library..

Regards= , Robert

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
 
 
------=_Part_1119_32375900.1373240454621-- .