[RFC] Support optional suffix parameter in tempnam

Hi On 8/14/23 17:57, Côme Chilliet wrote:

As per the documentation of tempnam:

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.

On Mon, Aug 14, 2023 at 05:57:53PM +0200, Côme Chilliet wrote:

Hi Côme, Thanks for the input and for going through the proposal. As the tempnam short description (https://www.php.net/manual/en/function.tempnam.php) states tempnam — __Create__ file with unique file name So tempnam 1) creates a file with specific permissions in a given path ($directory); and 2) returns the full path of the created file on success. For the sole purpose of obtaining a file path (2), I see no reasons for not using "tempnam($directory, $prefix).$suffix" as you suggested. However, to create the temporary file (1) allowing appending a suffix string to the created file, we would need to change tempnam. This is the purpose of this RFC. In other words, although the return value of "tempnam($directory, $prefix).$suffix" and the proposed "tempnam($directory, $prefix, $suffix)" __may__ be the same, the outcome of running each of those, is not. The second paragraph of the RFC introduction says "It would be useful to allow users to also specify a suffix when __generating__ temporary files. [...]" Do you have any suggestions on how we could improve the RFC introduction text to make this clearer to readers of this RFC?