Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106754 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38521 invoked from network); 28 Aug 2019 19:39:17 -0000 Received: from unknown (HELO zeona.lv) (213.175.74.1) by pb1.pair.com with SMTP; 28 Aug 2019 19:39:17 -0000 Received: from MezhRoze (unknown [10.8.0.69]) by zeona.lv (Postfix) with ESMTP id BB3192009981C for ; Wed, 28 Aug 2019 20:11:28 +0300 (EEST) To: References: <7ddbae5c-7451-4094-8b32-19676128054b@thelounge.net> <5d6699ce.1c69fb81.e9b71.2525SMTPIN_ADDED_MISSING@mx.google.com> In-Reply-To: Date: Wed, 28 Aug 2019 20:11:27 +0300 Message-ID: <007b01d55dc3$a0d49570$e27dc050$@roze.lv> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: lv Thread-Index: AdVdu2MWwZSIZpXuS4Ckv3cKupcfoAAAVfSQ Subject: RE: [PHP-DEV] [RFC] Reclassifying engine warnings From: r@roze.lv ("Reinis Rozitis") > "It's like our company car still works, but it no longer tighter meets = emissions > standards so they won't let us take it into the city any more" That's a very interesting way to describe error level changes of a = language. I wonder what happens when the manager asks - "What's with those guys = who bought python/java trucks, go-carts? Do they also have these co2 = problems?" Sorry for offtopic .. On a semi related note if the idea/discussion/RFC is for a betterment of = language and future regarding warning/errors, it has always puzzled me: - why the engine is so minimalistic/unspecified regarding max_input_vars = where the error is just "php-fpm: PHP Warning: Unknown: Input variables = exceeded 1000. To increase the limit change max_input_vars in php.ini. = in Unknown on line 0" which isn't very helpful. Also is E_WARNING enough in this case since the variables are forcefully = truncated?=20 - and the second is memory_limit which again without any external = tooling and/or debug mode while shows the file and line doesn't actually = produce meaningful error/backtrace to indicate the problematic part = (especially in production environments)=20 We have patched the zend_alloc (in a rough way by searching through = symbol_table for fastcgi params) to print more details at least in the = fpm-sapi to be able to replicate the issue more easily, but then again I = doubt it's the right way to do so.. While the second is hardly related (except the fact it's some sort of = programming error condition) doesn't the first one need the same = reclassification of error level as undefined variables? rr