Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122637
Message-ID: <b6490385-7ce7-4de0-8bd8-97ba784d26d9@gmail.com>
Date: Thu, 14 Mar 2024 12:46:46 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] base64_encode without padding
To: internals@lists.php.net
References: <9114cbe3-2b9c-4037-856b-20afc8f96f95@FamilleCollet.com>
Content-Language: en-US
In-Reply-To: <9114cbe3-2b9c-4037-856b-20afc8f96f95@FamilleCollet.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: dik.takken@gmail.com (Dik Takken)

On 13-03-2024 17:06, Remi Collet wrote:
> I think padding should be optional (on by default to keep BC)
> 
> Of course in user land, simple to write
> 
>    $enc = trim(base64_encode('foo'), '=');
> 
> This proposal allow to simply use
> 
>    $enc = base64_encode('foo', PHP_BASE64_NO_PADDING);
> 
> And also expose it for extension as
> 
>    PHPAPI extern zend_string *php_base64_encode_ex
>      (const unsigned char *, size_t, zend_long flags);
> 
> 
> Use case: for ARGON2 password hashing
> see https://github.com/php/php-src/pull/13635
> 
> It may seems ugly to add and remove th padding char
> 
> Is a RFC needed for such a minor feature ?
> 
> 
> Remi

Great addition! Only I would strongly prefer a boolean argument over a 
flag. Especially now that we have named arguments, adding a bunch of 
optional boolean arguments to the signature does not lead to unreadable 
code anymore. In fact, I think it yields code that is easier to read.

Regards,
Dik