Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:130280 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 0F09B1A00BC for ; Mon, 9 Mar 2026 16:28:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1773073702; bh=+U1xxD07BRP3gbdV86g/jbyomy7urtjTsr2V8lB8RD8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=btqDIkGUz0+R81FMGQDmqCgfUH4y9WLBY69Bc2G4+NERSrLz8z4c6AC8HTtyw+cD7 +TXro2qcwfSzK/JmjMEdZB8w34EemKDzF0B3ejmVEfMmUv0wdrugDem6baMW1Nr9b7 mM84X091OWjtm1tq6am5jylbn2LAaj9ESxxqDcP0PWRFJpQZjjN5JNDcbjzxSJnltS gOsYmQx0ofUXN4clGVFnH+WxFuULeGxEIxqetHNPqr4WeMGApEP1162l+05otmd8EB F3KouSwwcicxpBbpJruZIpoSqUcWJ78fIfJBg2LeDXDrn2pD30iSZ4nEdm7r/L13pU SKV/l0yAqzqGA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8B5091801E4 for ; Mon, 9 Mar 2026 16:28:21 +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.7 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DMARC_NONE,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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: No X-Envelope-From: Received: from mail-oa1-f53.google.com (mail-oa1-f53.google.com [209.85.160.53]) (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 ; Mon, 9 Mar 2026 16:28:21 +0000 (UTC) Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-40974bf7781so4986253fac.0 for ; Mon, 09 Mar 2026 09:28:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773073695; cv=none; d=google.com; s=arc-20240605; b=FTgTwNto1IRSZai8eZv1MGQcKcpRhUocdKsUTnorz6JyTw8+KjMW5mJpO9BQIVoFS9 pXZfzytryzt/gYOMrtPpIoZDpsfIDROI5zOxqfXaHj5uk+SBg1Kb7DuyfVF6jWELOD0r 0y9UaHexjjVIkey+YyIMskkWJuse32REBTbum7HmiLsdc8VBiBzkNYUj0ETtb4qREzNL pYvGaDBL/QaKr9woof7iJGW+ZnYbGyufTXH9AwR6JHHwXCdeZ6coxLUUkP38rO0jPfdv AbeTcXdf88JNAvXGn+hbMfbqdAUQP5IdOPdkJqnCq9zo243Tut7xyOQcbCLTgoR1tNou Vzdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version; bh=SQQLFhd8RwUlyLRa8fCXdHnO+Hbu3UPrSiwJ0QvT7gs=; fh=JcrAjFsG2j97Q+g4r6FSxz5+RlNWaIMOoPKfJ9vlqCw=; b=FS/CJnmtcn56XfqJAtNHPe/GRmZ2L8i/chyEWdcn/XMk7d0PVeCLwmdvZYxfh977dL mHLIQ/iPHOVBg/z9ffco7oQtU1mZqCOtuV32ufEu6tliqcqp+hW0bAMmx0XVOcl8M3pb JH4bmMsfAFMAOfuErtN0Lq3u16F+7X/TfcxiC8kAuAHRVK0GeYWI6V8V/0aNMVTOXKtP ReEMb3un/jA9iXlqU9XcNqYVwFsTLf4vtivl4ssdkTLXGwc9bOVm37zz8h09CihDPKrv TJ6orb5DrItYUUPxHFXCbz5sOEF4ZLCnSaMWdSCZ2aP5YvITSlFuhBDB4QPVvPy3D5LG yTOg==; darn=lists.php.net ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773073695; x=1773678495; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SQQLFhd8RwUlyLRa8fCXdHnO+Hbu3UPrSiwJ0QvT7gs=; b=TBh4pQbMC0ZspL6jYsNCNv/j0E/zxWVv/Wisd4Sj702HoA7YsmFQWQNs6eTk1G5gMi 4yu0j/VTKMCDSKW15k85gBlwJZ6rS8LxU9Jz4ykQ8MZV0LooW3sWYo0SqkdeI6JrPzp6 CwVeZcqZybyhiQZANFRgqxUpCEIn3hDe9uKV7nE8JABseK3pAvKwy4meB/splTqFRINg PQInaej0Z50mqx5yJAOyP3CWw3risiIcvDxI3pN3FO0949Q5vxtcEyI3OgUvwdOnqVGz lnLdRflV9XISiMgideKrspfCmuVoRKCquWLYKQ1hyP10UmL8Jg77mE7B8YxAsJP4Ulu/ xLaw== X-Forwarded-Encrypted: i=1; AJvYcCWhv/X5ij2QYFC146Hb35eVnGKAAGPSXkJwtUs7D+/qJ+YxlQbJTjby5ffhSY3enools+xoS7c6snA=@lists.php.net X-Gm-Message-State: AOJu0YyYKvjyZcKZZY2c8navhoUSL+WVU/5VXxFpWyxES2zDkJSfHvdP xRdEufn91QlRs5krKrqb2O0pvhV/8P2Rka6x4nsoOp5GWWvDo+8wUixNiOTcYtvfmFqSh7rcfAU mxyZ/nv5OGa6NJEr4a+YOvWBWMdDdcSs= X-Gm-Gg: ATEYQzz9HCHg2SApczg+UF3iImQEp7DyNw+Nzj2KDHATNOU/Wr3dGnMrHmL0qB0/l4V LRxe9iCVqAAN/e1K6m3s+xjPjuc7My+6S+o/9bSI+hjNBBPtQggYtNd/mlXZpbsLtv3CV42xNOo RdwS3l/zHnaHSsJPxxZbT4wotc3tgOuV5J5JIxdj/2oWBnDVlp8Kv1VUhQKBVc1Hav3uhl/R5Lo pBw57CECsHejxZBK6fzRZM4Mc9lNK64tr7dx3yAq9vRE4Xk0VLhLHyeao8I4SuPl7FQphdWj+G5 O7ase3o= X-Received: by 2002:a05:6871:8918:b0:404:1ec2:562c with SMTP id 586e51a60fabf-417568149f5mr129635fac.6.1773073695461; Mon, 09 Mar 2026 09:28:15 -0700 (PDT) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <650FCF24-CDBD-4F37-BA50-6D691EE3E3E1@cschneid.com> In-Reply-To: Date: Mon, 9 Mar 2026 17:28:04 +0100 X-Gm-Features: AaiRm50-gJGB8vxyuSc5Ss66tcFZYcXz-lD2to3-2fsA8owvWC_eQgKMzBJKMS4 Message-ID: Subject: Re: [PHP-DEV] [RFC] Exempt input type and value validation from BC Break policy To: Kamil Tekiela Cc: "Gina P. Banyard" , Christian Schneider , PHP internals Content-Type: multipart/alternative; boundary="000000000000c752a1064c99e39e" From: bukka@php.net (Jakub Zelenka) --000000000000c752a1064c99e39e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Mon, Mar 9, 2026 at 2:55=E2=80=AFPM Kamil Tekiela = wrote: > On Mon, 9 Mar 2026 at 13:37, Gina P. Banyard wrote: > > > > On Monday, 2 March 2026 at 19:54, Christian Schneider < > cschneid@cschneid.com> wrote: > > > > > Am 02.03.2026 um 20:12 schrieb Tim D=C3=BCsterhus : > > > > On 3/2/26 14:49, Christian Schneider wrote: > > > >> Playing my favourite broken record: > > > >> Can we please state that additions of Exceptions should (in most > cases) go through an E_WARNING phase to allow a time window to fix code > before changing the behaviour? > > > > > > > > =E2=80=9CNot passing invalid values=E2=80=9D is perfectly backwards= compatible. > Folks can just fix their code before upgrading their production deploymen= t > to the new PHP version, e.g. by trying out the new PHP version in a stagi= ng > system or running CI for both the old and new PHP version. > > > > > > - Not everybody has access to a staging system, e.g. people running > stuff on hosting services. > > > - As a hoster I'd rather have a phase where my customers get warnings > instead of errors, creates less emergency support load. > > > > > > > In practice an E_WARNING is no less breaking than going straight to > an Error, because: > > > > 1. The common frameworks include error handlers that just convert > any warning and notice to an Exception. > > > > > > So in that sense there is also no advantage to NOT having a warning > phase for those people. > > > But people treating E_WARNING different from Exceptions (which is > probably the exact people whose code breaks with an immediate Exception) = do > have a time window to fix things. > > > > > > > 2. The code is already broken, because it relies on unspecified > behavior. The error would just making the user aware that the code is ver= y > likely not doing what it appears to be doing based on the input values > passed to a function. > > > > > > It can easily do something valid and ignore the extra bits (pun kind > of intended), see > > > mkdir("foo", 070777); > > > which passes extra bits with are ignored but the application was > behaving in a completely deterministic and valid way. > > > > > > > Going through an E_WARNING would add maintainer busywork and > complicate the php-src codebase for no real gain. > > > > > > We've been over this before: > > > If people *really* feel that the additional burden to change the code > twice then I'd be happy to volunteer providing a small helper > function/macro to generate an E_WARNING and either (the more aggressive > approach) switch to an exception once a certain PHP version is reached or > (probably the more flexible way) issue a compile time warning/error > informing the maintainer to switch the warning to an Exception. > > > The most simplistic version of this is a FIXME comment annotated with > a version number. Easy to grep, easy to trigger automatic alerts about on= ce > the specified version is reached, but it can also be something more > sophisticated.. > > > One way or the other could also be integrated into the CI/CD system. > > > > > > Our main disagreement is about the "no real gain" part as it IMHO > targets the long tail of PHP code / developers out there not using > full-fledged frameworks and dev environments or running legacy software o= n > hosting services. > > > > > > I am very much in favor of making things easy for the code developers > but I am of the strong believe that it can be done in a good way for > developers. > > > > I don't see how going through an E_WARNING phase is helpful, rather I > see it as detrimental. > > Foremost, what is the behaviour of introducing a warning? > > Do we exit early and return false? > > Or do we just warn and continue to use a possible default or nonsensica= l > value? > > AFAIK every time a warning got introduced it followed the first > approach, so this doesn't seem to address the concern of giving developer= s > more time. > > However, if we do continue using the prior behaviour then we haven't > solved the concern in the slightest. > > As it may be a warning for one PHP version and in the next PHP version > the extension supports a new flag which removes the warning for that valu= e, > leading back to a silent BC break if the warning wasn't addressed. > > > > Another technical aspect is that warnings allows userland code to run > and change the state of the VM and extension in unexpected way (we have > countless fuzzying reports about this) an issue that does not exist with > Exceptions. > > > > Then comes the topic about how long should it be a warning? Until the > next major? A single release cycle? I don't want warning promotion to > become the same exhausting discussion that deprecation duration already i= s. > > > > I have no idea how you handle hosting, but when I used shared hosting i= n > the past I would never have anyone tell me that my code was producing > warnings or notices. > > And even the one website I manage for someone which is on OVH shared > hosting I can still select a PHP version (heck even downgrading to 5.4 fo= r > some reason). > > So I'm struggling to see how for the average end user this is impacting > them? > > And if you do just bump the PHP version for them, I'm not sure what's > the difference between having an Error immediately or producing warnings > for X years before throwing an Error and breaking > > > > Best regards, > > > > Gina P. Banyard > > I am in favour of exempting the validation errors from requiring RFCs, > and as Gina, I do not believe that warnings are useful. I don't like > that warnings even exist in the PHP language. I can see the case that > you don't want to break a running application by upgrading the PHP > version, but it can happen regardless. Minor PHP releases can contain > minor breaking changes and each time someone upgrades PHP, they should > run their test suite and verify that the application still works the > same as before. Whether we introduce a Warning or ValueError, it will > be caught during the upgrade process and fixed. It may even help avoid > nasty bugs if the application stops on invalid input; something which > could go unnoticed if it were only a warning. > > Well the mentioned breaking changes must all go through RFC - that's our policy. The reason is that breaking changes should get always a bit more consideration. It doesn't mean that they cannot be done. If this RFC passes, then the ValueError conversion can be done without RFC unless there is an objection - it means any core developer can still require RFC if they wish. > I am, however, concerned about one thing. If we don't require RFCs > there may be situations when a contentious validation is introduced. > For example, many validations can be implemented in such a way that > they don't cause additional performance loss, but let's say someone > decides that validating the value provides more benefit than the > performance cost. Without RFC, the community cannot share their > feedback, and one person's opinion wins. But if the function is used > with the correct values 99.99% of the time and it's used in the hot > code, the performance cost isn't worth catching the accidental invalid > value. > We could probably relay on some developers noticing such changes and calling for RFC which can be done for any feature. But my worry is that some of the cases that could be problematic just slip in and they might cause problems for users later. So my preference is to require RFC for all which should make sure that there is a good visibility for any such change. Those changes are usually trivial so grouping them to a single RFC should not be that much work. Kind regards, Jakub --000000000000c752a1064c99e39e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Mar 9, 2026 at 2:55= =E2=80=AFPM Kamil Tekiela <tekie= la246@gmail.com> wrote:
On Mon, 9 Mar 2026 at 13:37, Gina P. Banyard <internals@g= pb.moe> wrote:
>
> On Monday, 2 March 2026 at 19:54, Christian Schneider <cschneid@cschneid.com>= ; wrote:
>
> > Am 02.03.2026 um 20:12 schrieb Tim D=C3=BCsterhus <tim@bastelstu.be>:
> > > On 3/2/26 14:49, Christian Schneider wrote:
> > >> Playing my favourite broken record:
> > >> Can we please state that additions of Exceptions should = (in most cases) go through an E_WARNING phase to allow a time window to fix= code before changing the behaviour?
> > >
> > > =E2=80=9CNot passing invalid values=E2=80=9D is perfectly ba= ckwards compatible. Folks can just fix their code before upgrading their pr= oduction deployment to the new PHP version, e.g. by trying out the new PHP = version in a staging system or running CI for both the old and new PHP vers= ion.
> >
> > - Not everybody has access to a staging system, e.g. people runni= ng stuff on hosting services.
> > - As a hoster I'd rather have a phase where my customers get = warnings instead of errors, creates less emergency support load.
> >
> > > In practice an E_WARNING is no less breaking than going stra= ight to an Error, because:
> > > 1. The common frameworks include error handlers that just co= nvert any warning and notice to an Exception.
> >
> > So in that sense there is also no advantage to NOT having a warni= ng phase for those people.
> > But people treating E_WARNING different from Exceptions (which is= probably the exact people whose code breaks with an immediate Exception) d= o have a time window to fix things.
> >
> > > 2. The code is already broken, because it relies on unspecif= ied behavior. The error would just making the user aware that the code is v= ery likely not doing what it appears to be doing based on the input values = passed to a function.
> >
> > It can easily do something valid and ignore the extra bits (pun k= ind of intended), see
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mkdir("foo", 070777);
> > which passes extra bits with are ignored but the application was = behaving in a completely deterministic and valid way.
> >
> > > Going through an E_WARNING would add maintainer busywork and= complicate the php-src codebase for no real gain.
> >
> > We've been over this before:
> > If people *really* feel that the additional burden to change the = code twice then I'd be happy to volunteer providing a small helper func= tion/macro to generate an E_WARNING and either (the more aggressive approac= h) switch to an exception once a certain PHP version is reached or=C2=A0 (p= robably the more flexible way) issue a compile time warning/error informing= the maintainer to switch the warning to an Exception.
> > The most simplistic version of this is a FIXME comment annotated = with a version number. Easy to grep, easy to trigger automatic alerts about= once the specified version is reached, but it can also be something more s= ophisticated..
> > One way or the other could also be integrated into the CI/CD syst= em.
> >
> > Our main disagreement is about the "no real gain" part = as it IMHO targets the long tail of PHP code / developers out there not usi= ng full-fledged frameworks and dev environments or running legacy software = on hosting services.
> >
> > I am very much in favor of making things easy for the code develo= pers but I am of the strong believe that it can be done in a good way for d= evelopers.
>
> I don't see how going through an E_WARNING phase is helpful, rathe= r I see it as detrimental.
> Foremost, what is the behaviour of introducing a warning?
> Do we exit early and return false?
> Or do we just warn and continue to use a possible default or nonsensic= al value?
> AFAIK every time a warning got introduced it followed the first approa= ch, so this doesn't seem to address the concern of giving developers mo= re time.
> However, if we do continue using the prior behaviour then we haven'= ;t solved the concern in the slightest.
> As it may be a warning for one PHP version and in the next PHP version= the extension supports a new flag which removes the warning for that value= , leading back to a silent BC break if the warning wasn't addressed. >
> Another technical aspect is that warnings allows userland code to run = and change the state of the VM and extension in unexpected way (we have cou= ntless fuzzying reports about this) an issue that does not exist with Excep= tions.
>
> Then comes the topic about how long should it be a warning? Until the = next major? A single release cycle? I don't want warning promotion to b= ecome the same exhausting discussion that deprecation duration already is.<= br> >
> I have no idea how you handle hosting, but when I used shared hosting = in the past I would never have anyone tell me that my code was producing wa= rnings or notices.
> And even the one website I manage for someone which is on OVH shared h= osting I can still select a PHP version (heck even downgrading to 5.4 for s= ome reason).
> So I'm struggling to see how for the average end user this is impa= cting them?
> And if you do just bump the PHP version for them, I'm not sure wha= t's the difference between having an Error immediately or producing war= nings for X years before throwing an Error and breaking
>
> Best regards,
>
> Gina P. Banyard

I am in favour of exempting the validation errors from requiring RFCs,
and as Gina, I do not believe that warnings are useful. I don't like that warnings even exist in the PHP language. I can see the case that
you don't want to break a running application by upgrading the PHP
version, but it can happen regardless. Minor PHP releases can contain
minor breaking changes and each time someone upgrades PHP, they should
run their test suite and verify that the application still works the
same as before. Whether we introduce a Warning or ValueError, it will
be caught during the upgrade process and fixed. It may even help avoid
nasty bugs if the application stops on invalid input; something which
could go unnoticed if it were only a warning.


Well the mentioned breaking changes mu= st all go through RFC - that's our policy. The reason is that breaking = changes should get always a bit more consideration. It doesn't mean tha= t they cannot be done. If this RFC passes, then the ValueError conversion c= an be done without RFC unless there is an objection - it means any core dev= eloper can still require RFC if they wish.
=C2=A0
I am, however, concerned about one thing. If we don't require RFCs
there may be situations when a contentious validation is introduced.
For example, many validations can be implemented in such a way that
they don't cause additional performance loss, but let's say someone=
decides that validating the value provides more benefit than the
performance cost. Without RFC, the community cannot share their
feedback, and one person's opinion wins. But if the function is used with the correct values 99.99% of the time and it's used in the hot
code, the performance cost isn't worth catching the accidental invalid<= br> value.

We could probably relay on some = developers noticing such changes and calling for RFC which can be done for = any feature. But my worry is that some of the cases that could be problemat= ic just slip in and they might cause problems for users later. So my prefer= ence is to require RFC for all which should make sure that there is a good = visibility for any such change. Those changes are usually trivial so groupi= ng them to a single RFC should not be that much work.

<= div>Kind regards,

Jakub
--000000000000c752a1064c99e39e--