Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120898
Message-ID: <fbaf0302-92f3-708e-a02f-4eb1d455bcf2@bastelstu.be>
Date: Mon, 14 Aug 2023 19:21:35 +0200
MIME-Version: 1.0
Content-Language: en-US
To: =?UTF-8?Q?C=c3=b4me_Chilliet?= <come@chilliet.eu>, internals@lists.php.net
References: <ZNKTRRvonNALq036@castor> <2446443.ElGaqSPkdT@come-prox15amd>
In-Reply-To: <2446443.ElGaqSPkdT@come-prox15amd>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Support optional suffix parameter in tempnam
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 8/14/23 17:57, Côme Chilliet wrote:
> The RFC does not explain what benefits brings using tempnam($directory, $prefix, $suffix) over using tempnam($directory, $prefix).$suffix , which you can already use?

As per the documentation of tempnam:

> Creates a file with a unique filename, with access permission set to 0600, in the specified directory.

The function does not just generate a filename, but also creates the 
file itself (with strict permissions) to "reserve" it and thus 
*guarantees* that there won't be a conflict. Manually appending a suffix 
does not have that property [1].

Best regards
Tim Düsterhus

[1] Though I'd like to note that using `$prefix . 
bin2hex(random_bytes(16)) . $suffix` as the filename will almost 
certainly [2] give you a conflict-free filename and doesn't have 
OS-specific behavior. That's why I personally don't bother with tempnam().

[2] Collision chance is less than 10^(-7) for 2^52 files.