Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120899
Date: Mon, 14 Aug 2023 14:49:36 -0300
To: internals@lists.php.net
Message-ID: <ZNppMCOBY48XXTGX@castor>
References: <ZNKTRRvonNALq036@castor>
 <2446443.ElGaqSPkdT@come-prox15amd>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2446443.ElGaqSPkdT@come-prox15amd>
Subject: Re: [PHP-DEV] [RFC] Support optional suffix parameter in tempnam
From: athoscribeiro@gmail.com (Athos Ribeiro)

On Mon, Aug 14, 2023 at 05:57:53PM +0200, Côme Chilliet wrote:
>Le mardi 8 août 2023, 21:11:01 CEST Athos Ribeiro a écrit :
>> Hi internals,
>>
>> As a follow-up on my previous message here
>> (https://marc.info/?l=php-internals&m=168912164828942&w=2),
>> I would like to start the discussion on the "Support optional suffix
>> parameter in tempnam" RFC.
>> https://wiki.php.net/rfc/tempnam-suffix-v2
>
>Hello,
>
>The RFC does not explain what benefits brings using tempnam($directory, $prefix, $suffix) over using tempnam($directory, $prefix).$suffix , which you can already use?
>
>Côme

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?

-- 
Athos Ribeiro