Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127836 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id BE0511A00BC for ; Wed, 2 Jul 2025 15:11:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1751468959; bh=vIAihzATN/wVFg/1DPuIvEnUFgNz3/AuU/bfDLAHfGI=; h=References:In-Reply-To:From:Date:Subject:To:From; b=Tv3THXYsl0SqhjTCLZU64KG1a9n2W3PEasEE7CctiLA3g/7vKNi4+3LCILtYpKca7 owSDVTntUE6OsD0xjZp7K3KHhnznanzuKArCy0CdpcyIIiA032eAdNePG3Zsu7Y76f OusxC85kvjf1PbuTWI+8oO61Lhs/mCaWLTRz9EThKy4JoYcfJropmlF1J/+j7JEOd7 rjlMdU04zup8aDa6N/d02JfxkLaa7KHqTBL2rqb10+BCbt3W0Kyye7SlyOkm06x31N jIC931v+1cQkPhBmkNdmCDhakhFBKHdPzlETgRtZk8iuv+hcjpaHrDKSe/aUeZKqp5 1F5zQnTWkXGCA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 806E8180068 for ; Wed, 2 Jul 2025 15:09:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,MANY_SPAN_IN_TEXT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 2 Jul 2025 15:09:15 +0000 (UTC) Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-b31d592bbe8so5334012a12.2 for ; Wed, 02 Jul 2025 08:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751469067; x=1752073867; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=0ukCVnb5sJRiTGNREhK3Cw0bayzp0MtO+Rvf07JqSpI=; b=kA7khixCSdvhTqkCKnA48W8+8GWArBvH4oS9mKQjszyMNhc1WuWoSGXEFUlVixk3GG 6/E+XD+sOcdSeRyPW+mRsnat5prdmnNsoqbr2xFK+4e3B/+Y0qFJDlve04Cgv1dIxnlW R89noAY66dqwJqJTqWrZpzUTNO0NSYBS3Lridurc9dnAb5i9MwY1MEXixZc/XrE3nt7S vjLgFeinvnNCUhrRDKyGU2s7w9YN6ty8FMOopJW4Th4we5MIo/XmjZV5mZNxoOvFx3sk MjDADXqBahCdmJz47qtGLrvQGYdIG51KD9Jnz+7ZnHl5h5/q/eiMRFmuJoK2NQIWYr3k mImw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751469067; x=1752073867; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0ukCVnb5sJRiTGNREhK3Cw0bayzp0MtO+Rvf07JqSpI=; b=bCCO8B7absGTBQbQySsKA1Y/OZM6cAY/0tos66z3YGi3JdPGJP4E6HRZHwvEIky8n5 D8sC1K3CoKaxeAsMgSHGza9xaasCBzYKQtn1eJ6t3+hUnjbNbcwBXVFWsDnJSi46Eok6 WUNsWOLJEIzNqMsXgfDux22GQHVT4+AVi6PCo1G0ZrkWHpNJdp6pPs0Omoo3MNEz1jO0 EFDR699KmYJEEbyBesgad+rI5LxLjF5esPqqr/188QkUeEyXDFUGHOo6XAnis7XaU8ry sRuMoMfjx5bvGjihOq7WG8aeuFaT2ITMMaCf7gK+ywls4plL+PAzs691J0jgEfBuN0Kf g1HQ== X-Forwarded-Encrypted: i=1; AJvYcCW4BI+t/f3tBl1uKZxMncjssyZml1Egsl4sGDNs/wF3T8DN9w4H9sszhD3fe+6RjVB5f3o1UYS6zW0=@lists.php.net X-Gm-Message-State: AOJu0YxVb6Bx5KQQrJLwQoucfS0qzq0eGu0R5z4EksXiN41UC0FL66J9 zPPotkTiMlai19YkC9XvdF91c6ZX4qlU2nz1WeZ5+W2JtRW/OA4yDOnkWofLpD4Krjtf5ZeQESP 8gwGKkvFzxYo2DGxxHSsRPyqlQyupBPQHJKfi X-Gm-Gg: ASbGncvXfT6kaUbvE3n9q/aq5ydHHDsNWdUhgIVUwjTY8LQstcusRfQOJ5FGZKsOCEP UbDq5NFjDfAWw7+rp0tgVFvvyPDMk9fMl3dXuVHF+AT+dD3M6Sjbz3wJUCZovOVNty9TyM32CDS 3IJiHdQ6Xpjqloj6RD/gJ7eWurfOJg4wkn2R34Wx7dHNqE2C3IRRU+tmD/5KyzXlpcF56BjyosQ WmNTNzzHARmNcDH X-Google-Smtp-Source: AGHT+IFMsVMnUuLJLuSfcM16H17LObUPs1fyOeriGudgjhZ3KU93MmxjBReKkt9oTU1SDDIp0LX7h2kZxel+aqvmqpY= X-Received: by 2002:a17:90b:3911:b0:313:2adc:b4c4 with SMTP id 98e67ed59e1d1-31a90be8b09mr4971431a91.24.1751469066701; Wed, 02 Jul 2025 08:11:06 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <348856E5-6A4E-455A-81AE-882832170168@rwec.co.uk> In-Reply-To: Date: Wed, 2 Jul 2025 17:10:55 +0200 X-Gm-Features: Ac12FXyplQdkIEa7FEtN-RvLlRiJKrAnlQGUYo7Nqlc20e6MWbEV5W_STFALEis Message-ID: Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API To: "Rowan Tommins [IMSoP]" , PHP Internals List Content-Type: multipart/alternative; boundary="0000000000008e4fc00638f3abdf" From: nyamsprod@gmail.com (ignace nyamagana butera) --0000000000008e4fc00638f3abdf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > Perhaps we should include an option in the new API to emulate the old > behaviour, named as "legacy" or "unsafe" and immediately soft-deprecated > with a note in the manual, similar to the MT_RAND_PHP mode in the > Randomizer API < > https://www.php.net/manual/en/random-engine-mt19937.construct.php> If I follow your reasoning, this would imply introducing a new case, `DecodingMode::Unsafe`, in the `DecodingMode` enum. This mode would replicate the current default behavior of `base64_decode`, but only within `Encoding\base64_decode`. ```php echo base64_decode('dG9=3D=3D=3D0bw??'); // returns 'toto' //would be portable to the new API using the following code echo Encoding\base64_decode('dG9=3D=3D=3D0bw??', decodingMode: Encoding\DecodingMode::Unsafe); // returns 'toto' ``` I would therefore propose that, for all other decoding functions, any attempt to use `DecodingMode::Unsafe` must result in an `UnableToDecodeException` being thrown. Additionally, we should define the timeline for the eventual deprecation of the current `base64_encode()`, `base64_decode()`, `hex2bin()` and `bin2hex()` functions since the new option will be automatically soft deprecated and removed at the same time as the current API. Should this deprecation take place during the PHP 8 cycle, with removal targeted for PHP 9? Or would it be more appropriate to defer the deprecation to the PHP 9 cycle, aiming for removal in PHP 10? Alternatively, should a second vote be held to determine the preferred deprecation timeline? My intuition is that phasing out those functions during PHP 9 and removing them in PHP 10 could help minimize disruption. However, I don=E2=80=99t currently have data to support that assumption. For completeness, the issue is less severe with `hex2bin` where a transparent migration path is possible ```php echo hex2bin('48656c6c6f2c20576f726c6421'); echo Encoding\base16_decode('48656c6c6f2c20576f726c6421', decodingMode: Encoding\DecodingMode::Lenient); // both codes will output: Hello, World // whereas echo Encoding\base16_decode('48656c6c6f2c20576f726c6421'); // will throw --0000000000008e4fc00638f3abdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Perh= aps we should include an option in the new API to emulate the old behaviour= , named as "legacy" or "unsafe" and immediately soft-de= precated with a note in the manual, similar to the MT_RAND_PHP mode in the = Randomizer API <https://www.php.net/manual/en/rando= m-engine-mt19937.construct.php>

If I follow your rea=
soning, this would imply introducing a new case, `DecodingMode::Unsafe`=
, in the `DecodingMode` enum. This mode would replicate t=
he current default behavior of `=
base64_decode`, but only within =
`Encoding\base64_decode`.

```p=
hp
echo base64_decode=
('dG9=3D=3D=3D0bw??'); // returns 'toto'
//would be portable to the new API usin=
g the following code
=
echo Encoding\base64_decode('dG9=3D=3D=3D0bw??', decodingMode: Enco=
ding\DecodingMode::Unsafe); // returns 'toto'
<=
/span>```

I would therefore propose that, for all other decoding functions, =
any attempt to use `DecodingMode=
::Unsafe` must result in an `UnableToDecodeException` being thrown.

Additionally, we sho=
uld define the timeline for the eventual deprecation of the current `base64_encode()`, `base64_d=
ecode()`, `hex2bin()` and `bin2hex()` functions since the new option will be automati=
cally soft deprecated and removed at the same time as the current API.
<=
br>Should this deprecation take place during the PHP 8 cycle, with removal =
targeted for PHP 9? Or would it be more appropriate to defer the deprecatio=
n to the PHP 9 cycle, aiming for removal in PHP 10?  Alternatively, should =
a second vote be held to determine the
preferred deprecation timeline?
My intuition is that phasing out those functions during PHP 9 and rem=
oving them in PHP 10 could help minimize disruption. However, I don=E2=80=
=99t currently have data to support that assumption.

For completenes=
s, the issue is less severe with `hex2bin` where a transparent m=
igration path is possible
```php
echo hex2bin('48656c6c6f2=
c20576f726c6421');
// both codes will output: Hello, World
// whereas
echo Encoding\base16_decode('48656c6c6f2c20=
576f726c6421'); // will throw
--0000000000008e4fc00638f3abdf--