Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104199 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18626 invoked from network); 5 Feb 2019 20:37:47 -0000 Received: from unknown (HELO mail-it1-f180.google.com) (209.85.166.180) by pb1.pair.com with SMTP; 5 Feb 2019 20:37:47 -0000 Received: by mail-it1-f180.google.com with SMTP id c9so10150257itj.1 for ; Tue, 05 Feb 2019 09:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S5+6XM9n4ds7ak7hIPQHF4rb7qYHvIwiFcGVaO1dPQE=; b=lwjps2iPsv21X8C5YgiZrWkNEo3Rfa200Cl3FKGjz1ROAHjadjKJAnyVLJMn6B2mIE A6vB9luhSV3fvtS8QKXpricWLowzsGr0UJi2koMkbZVd0UsPxGTa4UMhKVpNOGExcO2d W3Efb5G3O5VNq4CfbqjgA4odzhvudGIXSdb9rOZkH8IBd0qyJ24dxQJ/tM2jjsVOlQFn 7QfzM57bDcXWY0HV8wLgbhITkYVWHUlQA6fEtp31VgwHZloY0sXmatYeUJzgStM4diEW J8cm0r9KxgxueXRJoYytZv6cDYp3ClyCA6q55fh+dYLUqxJWPIK74h473vqXGisTvBAX n/3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S5+6XM9n4ds7ak7hIPQHF4rb7qYHvIwiFcGVaO1dPQE=; b=V6RM4yFX5Uuc+Zf+cJbdGXvP6IonhXxMe2bfetjeZmrK4Hy1Vv8VAhpEck2Biss6/R PJXGpeHKmnOuYjaw04d9fND1YEcLlQbChFOQdZowmU9icOVGizG5hkTAnXUcQp7ul9F0 IW/Hy9ez8eWTDcHLlkHsU/956hBHMv9nIDwHVEDuc08GEpOsHq6eGdzX2Qm9XWpUvNLy ZZBXMK7NHHnsEms03lW6Vf1UzbMM+W4W39NWljvjo8n03F4nv9z87q7BaEMazqGqPCMH mPl0eLGeKfGLYxN5jZ9rX+yr/5vqzVifYqjj9LKgrcmftTvCJR+JLvTKgtEUUXNV4l+Q HS4A== X-Gm-Message-State: AHQUAub32GvgPR52ZfbIZk3b0eAtmXZYLnqIhM8ajLI/4PdbmezCDpLi ruz3+RCb4mjVlD4d0VpyqceiarGJO+zm0RU7Tm0dow== X-Google-Smtp-Source: AHgI3Ib6vCrJvFOhPJGtyHZiq7TWvr2J8HSmrOxrzJjOKBRkXzZAzDDw7CmrUjqRFc4U/m3mQvhsjsW2udsKKV58nD8= X-Received: by 2002:a02:410e:: with SMTP id x14mr3045786jaa.36.1549387137264; Tue, 05 Feb 2019 09:18:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 5 Feb 2019 18:18:39 +0100 Message-ID: To: Zeev Suraski Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000efaf97058128cd2a" Subject: Re: [PHP-DEV] Re: Don't silence fatal errors From: nikita.ppv@gmail.com (Nikita Popov) --000000000000efaf97058128cd2a Content-Type: text/plain; charset="UTF-8" On Tue, Feb 5, 2019 at 5:55 PM Zeev Suraski wrote: > On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov wrote: > >> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov >> wrote: >> >> >> I'd like to move forward with this change. I think the overall reception >> here has been positive, although in the discussion some other >> possibilities >> that avoid/reduce the BC aspect have been discussed. I think now that we >> have a PHP 8 branch, it would make sense to apply this as-is. The BC break >> is quite minor (compared to the other changes in PHP 8) and I think this >> is >> the cleanest way to solve the problem, as it only changes the list of >> silences errors, without introducing any new error handling concepts or >> mechanisms. > > > I don't think that other changes that may or may not make it into PHP 8 > should influence our decision - BC breaks accumulate and the more you have > of them, the more difficult it is to migrate. I'm also present unaware of > anything we already decided to 'break' in PHP 8 as of now (with the > exception of the removal of deprecated 7.x features). > > That said - I think we all agree the BC breakage scope is small - but at > the same time, it may be quite fatal for those that are affected. Those > who have display_errors on (which is both horrible for production and at > the same time fairly popular) are risking exposing sensitive data that > beforehand, they were safely and explicitly hiding using @. > I can see the general concern here, but I'm having a hard time imagining that this will be an issue in practice. If you have display_errors=on you are at risk of leaking information in error messages with or without this change. The prime example of leaking information, which is passwords contained in the exception stack trace of a failed PDO connection, isn't even affected by this, because the silencing will be removed as part of exception unwinding anyway. > Is there any reason *not* to do it in such a way that provides a gentler > migration path? Introduce a new error level that would be a part of E_ALL > in 7.4, but outside of E_ALL in 8.0 - that would govern whether fatal > errors are silenced or not. > The reason not to do it is pretty much the same as always: Adding that new error level is basically the same as adding a new ini setting (and if we do want that, then I think it should be it's own ini setting and not hacked in as part of error_reporting), and you know our usual opinion on that topic. Furthermore, in this particular case it would also defeat the purpose of the change. If we set the option such that fatals are silenced by default, then we may as well not make the change, because the people who benefit most from it (non-expert users) are not going to change that default. Conversely, if we do not silence fatals by default, then we don't solve the issue with display_errors=on you mentioned above (as it requires explicitly setting an option, in which case they could just set display_errors=off instead.) Nikita --000000000000efaf97058128cd2a--