PHP undefined vars / array indices
Any PHP coders out there? So PHP really did it in 8.0: They really made accessing undefined vars *and* array indices a full warning rather than a notice. I had written in past newsletters that I hoped this didn't mean what it sounded like it meant. But it does. They really did it. https://wiki.php.net/rfc/engine_warnings I finally had to face the music with the upgraded MUUG server which now uses PHP8. It was coming for me in Fedora 25 anyhow (maybe 4 more months to postpone that change). The MUUG server is about 80% code that Allan Pollard wrote (thanks Allan!) and 20% my own code. Neither wrote according to PHP8's magic new requirements. Anyone here who does PHP and hasn't treated it as a typed / declared language, because it is not one, is in for a great deal of pain when they are forced to upgrade to PHP 8. I'm not sure I've ever come across existing PHP code where the dev treated it as a language where you must pre-declare everything. Of course, such people must exist, as exhibited by the voting record for this PHP RFC. Perhaps they are people who only recently took up PHP and/or are coming from stricter languages. And that is my main beef: if you want a strict language, use a strict language. Why take a loose language, which has always been loose and is loose by design, and suddenly make a major change that is going to spew out errors all over everyone's screen (if display_errors is on) for 90% of all legacy code? If I want strict variable declaration, I'll use one of the zillion languages that force you, and even do nice compile-time checks for you. And you just know that while, at the moment, this change is limited to making it a warning, the tyrants are itching to make this a full explosion error. You can see it in the voting ("Change undefined variable severity to?": vote 36 to 28). Luckily for us PHP requires a 2/3 majority to pass an RFC. To "fix" these errors in code, you can in most cases use a lot of tricks, like massive use of ?? everywhere. But that makes the code look really ugly and I start to question why? And if you use list() to capture results of a function which can return variable type of variable length arrays, you're really in trouble as there's no current syntax to combine ?? or isset() with that. Sure, you can go in and turn your PHP into C by pre-declaring every variable, if you can spot them all in complex functions or global scope code. But that only helps you with the "undefined variables" thing, not the "undefined array index" thing. The latter is far more insidious because your index can be a variable itself! So for that case you must always use isset() or ?? or some other trick. I could go into more examples of what I had to do to the MUUG code if anyone is interested. So what can you do in the real world? The first thing you do is turn off display_errors, which is probably off on production boxes anyhow (but wasn't on "hobby" boxes like MUUG, but it is now). Then make sure those warnings are being logged. Then sit back and let people use your site and wait for the MBs of log lines saying undefined this and that. Then you have a choice: a) ignore it all and set your logrotate to a short period of time so you don't fill your log disks; or b) fix every error that shows up. I did (b) on MUUG and it's not fun, and that's just a small code base. In either case you must pray the PHP tyrants don't soon vote this into a runtime exception error, as when you retrofit your old code you're almost never going to find every instance of this. Compare this situation with perl strict. Perl introduced "strict" mode with "use strict" a long time ago. That makes you my() every variable and its dog or you get a full blown error. But I'm pretty sure it doesn't affect array indices. In any event, if you don't agree with the perl devs, you just write "no strict" (or just disable this specific strict). No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP? PHP could have made it a configurable option. It would be really easy. But they didn't. I have some projects with over 100k lines of PHP code. The simple fact that "fixing" this will make my code look extremely ugly, harder to read, less maintainable, and probably more prone to bugs is all the reason I need to decide that I will never "fix" my code. Not to mention it will be probably 20k lines of code that need to be "fixed", and it's a pointless pursuit because in the end I'll never find them all. (grep -P '\[' ... ya right.) So it will be log & ignore, or not log at all (though I still will need to see legit warnings somehow); or git clone php and change 2 lines of code and maintain my own version forever. In fact, it may be time to do a fork of PHP: sane-php or something. Lastly, I'm willing to debate the philosophical points, especially using the RFC's wording as a basis; however, I'm not sure anyone is interested in taking the other side (please, hardcore PHP programmers only). I'll leave you with the arrogant wording from the RFC: In most cases, accessing an undefined variable is a severe programming error. The current low classification is a legacy from the Dark Ages of PHP, where features like register_globals made conditionally defined variables more typical, and code quality standards were lower. [...] However, throwing an exception may complicate the upgrading of legacy code that currently suppresses the generation of notices wholesale, as the issue can no longer be ignored. Some people have even suggested that the use of undefined variables is a legitimate coding style choice. "Legacy", "Dark Ages" indeed. Nice framing. "Legitimate coding style choice." How gracious.
On Sat, 2022-01-08 at 03:34 -0600, Trevor Cordes wrote:
Any PHP coders out there?
Hi, Trevor. PHP coder out here. A subscriber friend of mine pointed me to your message, and was kind enough to send it to me unmodified so as not to break threading (hopefully it works).
So PHP really did it in 8.0: They really made accessing undefined vars *and* array indices a full warning rather than a notice. I had written in past newsletters that I hoped this didn't mean what it sounded like it meant.
But it does.
They really did it.
https://wiki.php.net/rfc/engine_warnings
I finally had to face the music with the upgraded MUUG server which now uses PHP8. It was coming for me in Fedora 25 anyhow (maybe 4 more months to postpone that change). The MUUG server is about 80% code that Allan Pollard wrote (thanks Allan!) and 20% my own code. Neither wrote according to PHP8's magic new requirements.
Anyone here who does PHP and hasn't treated it as a typed / declared language, because it is not one, is in for a great deal of pain when they are forced to upgrade to PHP 8. I'm not sure I've ever come across existing PHP code where the dev treated it as a language where you must pre-declare everything. Of course, such people must exist, as exhibited by the voting record for this PHP RFC. Perhaps they are people who only recently took up PHP and/or are coming from stricter languages.
I sympathize with your plight as you're dealing with an older code- base, but I sympathize only so much. Notices are not and have never been spurious messages which are safe to ignore: they are indications of possible logic errors, and a well-disciplined PHP programmer ought to be using error_reporting(\E_ALL) when testing and addressing each and every notice (and deprecation warning!) they encounter. Moreover, recommended configuration today is to print no error messages whatsoever (they should all go to a log file) when deploying to the public, so the change really shouldn't have any effect on a host which is properly configured; you'll just have more warning to look at in logs instead of notices. In my view it was a mistake for PHP deployments in the PHP 4 shared- host days to typically suppress notices; you had to go out of your way to even know whether you were writing robust code, and it's given the impression that a lot of coding behaviour which has always been considered suspect is actually perfectly fine.
And you just know that while, at the moment, this change is limited to making it a warning, the tyrants are itching to make this a full explosion error. You can see it in the voting ("Change undefined variable severity to?": vote 36 to 28). Luckily for us PHP requires a 2/3 majority to pass an RFC.
I disagree with your characterization of the 36 who voted in favour of an error exception as tyrants, though I do agree it would have been a step too far. The elimination of simple-majority votes on RFCs is, funnily enough, perhaps one of the best changes to PHP in recent memory: it holds its stewards to a higher standard of feature design, which means we've tended to get better features since. I should point out (since I don't believe you did) that the RFC had separate votes for "undefined variable" and "undefined array index", and throwing an exception was never a voting option for the latter. Thus I suspect it was recognized that the former would be easier to adapt to, and the latter impractical. It was presumably also a recognition that a missing array index is more likely to be a data quality problem, whereas reading an undefined variable is (almost) always going to be a logic error on the part of the programmer.
To "fix" these errors in code, you can in most cases use a lot of tricks, like massive use of ?? everywhere. But that makes the code look really ugly and I start to question why? And if you use list() to capture results of a function which can return variable type of variable length arrays, you're really in trouble as there's no current syntax to combine ?? or isset() with that.
Your example with list() is a good one. At its core this is a run-of- the-mill input validation concern, though. Example: [jking@odin ~]$ php -a Interactive shell php > error_reporting(\E_ALL); php > $v = ["ook", "eek"]; php > [$ook, $eek, $ack] = $v; PHP Warning: Undefined array key 2 in php shell code on line 1 php > [$ook, $eek, $ack] = array_pad($v, 3, null); php > That notices have historically been hidden does not excuse you from checking your inputs and/or correcting them where needed.
Sure, you can go in and turn your PHP into C by pre-declaring every variable, if you can spot them all in complex functions or global scope code. But that only helps you with the "undefined variables" thing, not the "undefined array index" thing. The latter is far more insidious because your index can be a variable itself! So for that case you must always use isset() or ?? or some other trick.
I could go into more examples of what I had to do to the MUUG code if anyone is interested.
I'll grant you that dealing with undefined array indices used to be kind of awkward, such that you had to pepper your code with a lot of isset() or array_key_exists() (depending on whether null is an expected value for an array member), but that's nevertheless what you had to do to have robust logic. The ?? operator is there to make correct code more concise, not just to make PHP shut up, and I was very happy about its introduction since I could eliminate a lot of wordy branches.
No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP?
In my opinion you proceed from a false assumption. As I stated above, accessing an undefined variable has always been an error (at least since PHP 4, if not earlier), albeit a putatively mild one. It is now merely less-mild. PHP is not strictly typed (though it does have a strict-type mode since PHP 7.0), but it has always preferred that one declares one's variables, and that preference has now been made stronger with PHP 8.0.
I have some projects with over 100k lines of PHP code. The simple fact that "fixing" this will make my code look extremely ugly, harder to read, less maintainable, and probably more prone to bugs is all the reason I need to decide that I will never "fix" my code. Not to mention it will be probably 20k lines of code that need to be "fixed", and it's a pointless pursuit because in the end I'll never find them all. (grep -P '\[' ... ya right.)
So it will be log & ignore, or not log at all (though I still will need to see legit warnings somehow); or git clone php and change 2 lines of code and maintain my own version forever. In fact, it may be time to do a fork of PHP: sane-php or something.
Again, I sympathize since you're dealing with an old code-base. I nevertheless believe you've been doing things wrong by treating notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
Lastly, I'm willing to debate the philosophical points, especially using the RFC's wording as a basis; however, I'm not sure anyone is interested in taking the other side (please, hardcore PHP programmers only).
I present as my bona fides the following: - A news aggregator which implements four different client-server sync protocols: <https://thearsse.com/> - An HTML parser which actually conforms to the specification: <https://packagist.org/packages/mensbeam/html-parser> - A character decoder which decodes bytes in various encodings into code points or UTF-8 characters: <https://packagist.org/packages/mensbeam/intl> - A Content-Type header-field parser: <https://packagist.org/packages/mensbeam/mimesniff> The latter two support the HTML parser, and the HTML parser will eventually support the news aggregator. It may interest you to know that the character decoder does blindly access beyond the end of a string (itself a warning since time immemorial), but suppresses the error at the call site (see <https://github.com/mensbeam/intl/blob/07d26e3f45c3a3167eb6389572419d3bda7ff5...
). This is something I should probably change since it can be a problem if a user of the library implements a custom error handler.
Further, the tokenizer of the HTML parser is one giant loop (see <https://github.com/mensbeam/HTML-Parser/blob/37f0fa8647ead67e5e9f356efe91df8...
), and not-yet-emitted tokens can be created in one iteration of the loop and manipulated in others. In the tokenizer an access of an uninitialized variable is unquestionably an error: a branch which manipulates a token should never have been encountered before the branch which initializes the token. Not having an indication of this (be it a notice or warning) would have made debugging harder, not easier.
The news aggregator has required me to write tons of code to sanitize input, including a function to give me more reasonable type juggling (see <https://github.com/mensbeam/arsse/blob/b6605080096918c8d6f8378aa6c31db0dbc2b...
) and a function for each sync protocol which makes sure the input is never missing any expected associative array keys and always has the correct type (see <https://github.com/mensbeam/arsse/blob/b6605080096918c8d6f8378aa6c31db0dbc2b... for the Tiny Tiny RSS implementation)
All of this is validated by tons and tons of automated tests which cover every single line of code (unless impractical or impossible to cover with PHPUnit). None of it should ever emit a notice (though one or two have slipped through over the years), and this discipline has unquestionably made my code better. -- J. King <jking@jkingweb.ca>
On 2022-01-10 J. King wrote:
I sympathize with your plight as you're dealing with an older code-
Thank you for your constructive and well-reasoned reply. It is nice to have another person to discuss this important issue with. (I apologize in advance for the length of this reply.) I think it's helpful to dissect the issue into three parts: the risk posed by the original status quo, and the pain of change, and the freedom of the programmer. In advance, I will readily grant that the uninitialized value (UV) problem is more often a possible "mistake" than the uninitialized array index (UAI) one. I would also guess it is much more rare. At least that is what my attempts to "fix" my code has revealed. But everything I discuss applies pretty much equally to both. And the PHP8 RFC, though it separated the issues, ended up lumping them into the same result: turning them both into warnings. Thus it follows that the arguments used to vilify one (UV) must closely or somewhat apply to the other (UAI). I've been using PHP (in production) since 1999 and v3. I'm nearly positive UV and UAIs were not even a notice back then. In fact, with the (yes, evil) register_globals they got rid of a long time ago (more below), the whole idea of knowing if a var was initialized or not was impossible (without jumping through the isset hoops which almost nobody did, especially since ?? didn't yet exist). So let's establish that PHP from v1 through v3 not only didn't care, it kind of mandated the programmer not check for uninitialized variables (UV). In other words, it not only said it was "ok", it said "this is the way it's done". I can go into any of my ancient PHP3 books (from many various publishers) and guarantee you I will not find one example that bothers to initialize a variable when there was no reason to. (See example #0 at bottom.) And that's ok, because many other loose, untyped, scripting languages that were popular around 1999 were exactly the same way (e.g. perl). In fact, I would posit that they were designed this way! It wasn't an oversight or laziness: it was the desire to have the programming language do more of the work for you, and to reduce the code line count (vs C) required to get a job done (hence why the scripting languages were considered "rapid" and (often) "prototype"). Were the developers of PHP in 1999 ignorant? Or were they trying to create a language suited for a purpose in a way that was similar to its peers and required "less work" than the heavy alternatives? So what's really the problem here? All I hear from the "pro" side is "times have changed", "it's not good practice", "it's not robust", "legacy", "possible logic errors", "doing things wrong". And they are saying the original makers of PHP, all the book authors from back then, and a generation of programmers who used it that way were/are wrong and must change (certainly by the time the "warning" is turned into a runtime error). OK, someone could have that opinion, I get it, especially someone using PHP for less than 5-10 years. But before they make me change 20k+ actual lines of code to make it uglier and less readable (IMO) they better have some really good, concrete arguments. The onus should be on the ones making the sweeping changes. As an aside, I have a B.Sc in CompSci (around the Java era, though I rarely used Java) and took every major related course, learning about 10 languages. Not once was I told I had to "initialize my variables", and certainly not check for UAI. Not once did I lose a mark for not doing so. If the language being used required it, then you did it. If it didn't, then all that mattered was having a correct, readable program. Maybe that has changed and all CompSci teachers now mandate initializing all variables in all programs in all languages. However, that kind of proves that this choice is rather arbitrary and more a function of "style". I looked for, but do not seem to have access to, the internal PHP discussions generated by that RFC, so I cannot know what arguments people were using on either side. I know what my main argument is: prove to me it's better, or safer, or any of the other condescending descriptors used in favor of banning UVs/UAIs. I have not been able to find a single concrete example of how UVs actually achieve this level of devilish behavior that will bring down the entire internet if left as notices instead of warnings. I would love to see some sample code a real, half-competent programmer would use that could result in a security hole. I can assure you that not one single program I've written in 30 years of script-language usage suffers from a bug caused by this. To bastardize Jerry McGuire: Show Me The Bugs! I would guess/hope a competent programmer would think like I do (and the original creators of PHP clearly did), and at every point they are going to use a variable (that they aren't staring at a previous use of on the same code page/scope) they say to themselves "this variable might be unset". The base assumption is *always* the variable is unset. Further, if you stick with the general paradigm that a value of 0 in your program is a negative indication (as is false, null, etc.) then unset is just as good! That is the precise reason one uses an untyped/loose-typed language! The language does the work of following its rules to massage $x into the form needed for if(!$x) or ++$x! I've been told often in situations like this that "not all programmers are competent" and so need such "hand holding" to protect themselves. I can understand that point, but why should it be *forced* on all of the competent programmers? Why are we *forcing* the lowest common denominator? Why aren't we allowing people and projects that have such people or needs to turn on a configuration option (or even make it the default)? Why don't we give those who don't need their hands held the option to stick with the multi-decade status quo? Perl did. Even insane-for-backwards-compatibility python did not institute a change between v2 and v3 that required changes to 5-20% of a codebase! At the bottom of the "I know better", "hold their hands" slope lies Logo. That is not useful to me. I have a few personal philosophies. One is "always forward, never back", especially when it comes to computers. I still use many perl scripts I wrote in 1992+ and haven't modified since. I use many others that required a line or two changed once in a while when the OS upgraded; in perl, php, python, js, etc. Same reason I use Linux/XFCE/sawfish instead of Windows or GNOME. If I'm going to spend a day coding or configuring, it's going to be to get something new done (i.e. make a new program) that will move me forward and build on my past efforts, not fighting with some arbitrary change foisted upon me that breaks everything in a horrific manner just to get me back to where I was yesterday! Those types of OSs and languages and software I expelled from my life ages ago. When PHP makes UV/UAI a runtime error, it will be the first time PHP has broken my rule, out of 23 years. (Perl has never broken this rule, out of 30+ years.) Register_globals makes for an interesting comparison. It was on by default, encouraged, and used everywhere until, what, PHP5 (or 4)? That feature has plainly obvious and trivial examples as to why it can be a risk and a security hole. In fact, the thing that made it a risk is precisely that it broke the promise that a var you didn't initialize was going to be unset. You had no clue what any random $identifier was going to contain, because it was externally controlled. The fact that the feature was killed like a decade ago proves it was a massively bigger risk than UV/UAI is now. So what about the fix/mitigation/pain aspect? Well, that was easy/quick relative to the mess UV/UAI causes. Just look at the handful of get/post (and cookie) vars your page expects (something that can be grepped!) and change them to $_GET[], et al, or "init" them yourself at the top with $expected=$_GET['expected']. A handful of lines to edit with a very low probability of introducing bugs. I remember when I had to do this to every script I ever wrote and it was quick and easy and painless. So the overall equation of minimizing risk vs the pain of the solution was extremely favorable. Now apply that same calculation to UV/UAI. I challenge you to illustrate for me that the two variables of the equation are similar to the register_globals situation. Likewise, I was appalled, and then relieved when the PHP devs said they wanted to get rid of <? ?> short tags but decided against it. It's very similar to the UV/UAI issue because it's a solution in search of a problem, something that has been used since day 1, actively encouraged, and the risk/pain equation is horrifically lopsided. And at least that problem can be grepped! UAI really cannot. That <? ?> came as close as it did to being deprecated/errored indicates that there is a real problem with the PHP leadership/voters' mindset where many really don't care at all about existing codebases or valuable programmer time.
I disagree with your characterization of the 36 who voted in favour of an error exception as tyrants, though I do agree it would have been a step too far. [...] notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
You agree it's a "step too far" but then hint in the second part what we all know is coming: one day (soon) PHP devs will change UV into a full blown error. I bet many are itching to make UAI one too! Give it a few extra years. However, I won't be crying, because I can, and will, tweak a few lines of PHP source code and compile my own (rpm tools on RH-based systems make this exceptionally easy). I've decided UV/UAI is insanity, especially if no one can explain how this is even a small security hole for *me*, and the path of least pain with equal gain is to maintain my own version, perhaps called "sane-php" or "freedom-php". I know for a fact I won't be the only one. UV/UAI and <? ?> nonsense is precisely what prompts people to flee a project, or fork. The reason there's not an uproar yet is that (some estimates) have PHP8 usage at only around 1% at the moment. Just wait until RHEL ships it by default and all the LTS Deb/Ubuntus with PHP7 go EOL. Heck, even Fedora had to delay PHP8 2 or 3 releases vs planned because it caused so much grief. One more thought: this UV/UAI "fix" could actually cause more security holes and less attention to notices/warnings overall because, as of now, the easy fix is to disable logging of warnings. If your site gets reams of traffic, you'll practically be forced to go ~E_WARNING, otherwise your log disks will fill up and you'll kill your SSD lifespan. That will cause "real" warnings (which I do want to see!) to go completely unnoticed. How is that a better result? I won't be the only one... It'll make dev a disaster because on a dev box, which will have display_errors=on, I won't see any of the egregious warnings in-page, making bug-free development that much harder. If the goal is to get more attention to warnings/notices, UV/UAI might actually do the opposite.
php > error_reporting(\E_ALL); php > $v = ["ook", "eek"]; php > [$ook, $eek, $ack] = $v; PHP Warning: Undefined array key 2 in php shell code on line 1
That notices have historically been hidden does not excuse you from checking your inputs and/or correcting them where needed.
What if the function returns 2 values in some cases, and 3 in others? Yes, that might not be a great design choice, but it's a legitimate one in that it can be logically correct. You are punishing the caller with a warning for a design choice inside the function (they may not have written). And you've given them no way work around it without a whole whack of extra, ugly lines of ?? or isset on a temporary result array variable. All that pain for what gain? Show me the security hole.
I'll grant you that dealing with undefined array indices used to be kind of awkward, such that you had to pepper your code with a lot of isset() or array_key_exists() (depending on whether null is an expected value for an array member), but that's nevertheless what you had to do to have robust logic.
Why? As above, prove it's "robust" vs the alternative. The RFC and random forum/bug discussions I've seen about this do nothing but bandy about the condescending descriptors with nary a shred of evidence of said "unrobustness".
No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP?
In my opinion you proceed from a false assumption. As I stated above, accessing an undefined variable has always been an error (at least since PHP 4, if not earlier), albeit a putatively mild one. It is now merely less-mild.
What is the false assumption? It is irrelevant that they made it a "notice" in PHP2, 3, 4 or 5, and a warning in 8. The main problem, which you don't address, is the freedom to choose. Why can't we have that freedom? Why do the 36 get to choose for the world and why do they seem so uniquely oblivious to existing codebases? I always thought python was bad, but at least they admit, that by design, they will screw you over every major release and always have! We are not talking about a change that allows the PHP language developers to rip out thousands of C lines of cruft or make the language perform 30% faster. We are talking about, I'm guessing, 1 to 10 lines of C code changed and 0% speedup. All for what?
Again, I sympathize since you're dealing with an old code-base. I nevertheless believe you've been doing things wrong by treating notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
I always code perl with -w on, but strict off. That's the equivalent of seeing all notices/warnings in PHP. In the olden days of PHP I'd log E_ALL because only "sane" things were warnings... kind of like perl. I don't know where along the way I ~E_NOTICEd, but over the years PHP has made enough non-problems into notices that, yes, I completely ignore notices now. Unlike in perl, they don't seem to ever match up with an "oopsy" moment: they simply moan about reams of style choices that I disagree with. I trusted the PHP devs to make good decisions as to what they were going to warn or deprecate, and I really have agreed with their choices on everything... until now. Now it feels like they've jumped on the "change for change's sake" bandwagon like some other FLOSS projects; or worse, the "our style is right and you'll like it" attitude. But at least most of those other projects, if forced to still use them, provided some gravy! There is zero upside *for me* for the PHP UV/UAI changes. Since I have no logic error or security hole in my program because of UV/UAI, the only "doing things wrong" I've done is to trust that the PHP braintrust will keep making sane choices and/or maintain my freedom to choose. I will end with a lame appeal to authority, but one that is meaningful to me as a longtime fan: Rasmus Lerdorf, inventor of PHP, UV vote "keep notice", UAI vote: "keep notice". Rasmus gets it. (Oh ya, and Linus would never allow a change like this in the Linux Kernel without massively obvious and good reasons. And...) APPENDIX: Example #0: function Foo { while ( ... ) if (!$i++) {} } Is a perfectly reasonable/concise, if lazy, paradigm for detecting the first time in a loop and keeping a count of iterations as a bonus. This is now a warning in PHP8. Is anything at all gained by putting "$i=0" before the while, maybe at the top of the page or the start of a function? If I wanted to be forced to do that, I'd be using a language that wants me to. And even if one thinks i=0 should be required, it's not universal, as perl happily accepts that without warning even with warnings on! perl sees that and says "the programmer has his big boy boots on and does not need coddling". Even with strict on, as long as you declared it with my($i) (even without initializing it!) perl doesn't complain.
As a former professional PHP programmer and current hobbyist programmer (not in PHP though), I agree with Trevor. (disclaimer: I did not go back and re-read all the PHP threads on this topic). PHP made a fundamental change to the way the language works which breaks backwards compatibility and has not provided any concrete evidence that supports the published justification for this change. "style" and "best practice" really are just opinions. I also don't see any reason why PHP could not have defined a global "use_strict= true/false" parameter similar to the approach that Perl took years back. The default could even be "true", if they want to emphasize the importance of it. However, I do agree that it's not good programming practice. Consider this example: function Foo { while ( $i < 5 ) if (!$i++) {} // ... (a whole bunch more lines of code go here) .. while ( $i < 5 ) // inadvertently using the same variable because $i is your favorite 'counter' and you forgot you already used it if (!$i++) { } // This line never runs } On a side note, you would only ever see "!$i++" syntax in non-declarative languages like PHP. It makes no sense otherwise since integers can never be false. Aside from that, my personal preference is to code for readability and I find the statement is hard to interpret. So I prefer: If ($i == false) { $i++ ... other stuff } But never the less the point is I agree that PHP should not have broken backward compatibility. By doing so it will force many sites to remain on PHP 7.x thereby opening up the very real possibility that a 7.x security vulnerability will get exploited and cause mass-grief (log4j anyone?). John On Thu, Jan 13, 2022 at 3:04 AM Trevor Cordes <trevor@tecnopolis.ca> wrote:
On 2022-01-10 J. King wrote:
I sympathize with your plight as you're dealing with an older code-
Thank you for your constructive and well-reasoned reply. It is nice to have another person to discuss this important issue with. (I apologize in advance for the length of this reply.)
I think it's helpful to dissect the issue into three parts: the risk posed by the original status quo, and the pain of change, and the freedom of the programmer. In advance, I will readily grant that the uninitialized value (UV) problem is more often a possible "mistake" than the uninitialized array index (UAI) one. I would also guess it is much more rare. At least that is what my attempts to "fix" my code has revealed. But everything I discuss applies pretty much equally to both. And the PHP8 RFC, though it separated the issues, ended up lumping them into the same result: turning them both into warnings. Thus it follows that the arguments used to vilify one (UV) must closely or somewhat apply to the other (UAI).
I've been using PHP (in production) since 1999 and v3. I'm nearly positive UV and UAIs were not even a notice back then. In fact, with the (yes, evil) register_globals they got rid of a long time ago (more below), the whole idea of knowing if a var was initialized or not was impossible (without jumping through the isset hoops which almost nobody did, especially since ?? didn't yet exist).
So let's establish that PHP from v1 through v3 not only didn't care, it kind of mandated the programmer not check for uninitialized variables (UV). In other words, it not only said it was "ok", it said "this is the way it's done". I can go into any of my ancient PHP3 books (from many various publishers) and guarantee you I will not find one example that bothers to initialize a variable when there was no reason to. (See example #0 at bottom.)
And that's ok, because many other loose, untyped, scripting languages that were popular around 1999 were exactly the same way (e.g. perl). In fact, I would posit that they were designed this way! It wasn't an oversight or laziness: it was the desire to have the programming language do more of the work for you, and to reduce the code line count (vs C) required to get a job done (hence why the scripting languages were considered "rapid" and (often) "prototype").
Were the developers of PHP in 1999 ignorant? Or were they trying to create a language suited for a purpose in a way that was similar to its peers and required "less work" than the heavy alternatives?
So what's really the problem here? All I hear from the "pro" side is "times have changed", "it's not good practice", "it's not robust", "legacy", "possible logic errors", "doing things wrong". And they are saying the original makers of PHP, all the book authors from back then, and a generation of programmers who used it that way were/are wrong and must change (certainly by the time the "warning" is turned into a runtime error). OK, someone could have that opinion, I get it, especially someone using PHP for less than 5-10 years. But before they make me change 20k+ actual lines of code to make it uglier and less readable (IMO) they better have some really good, concrete arguments. The onus should be on the ones making the sweeping changes.
As an aside, I have a B.Sc in CompSci (around the Java era, though I rarely used Java) and took every major related course, learning about 10 languages. Not once was I told I had to "initialize my variables", and certainly not check for UAI. Not once did I lose a mark for not doing so. If the language being used required it, then you did it. If it didn't, then all that mattered was having a correct, readable program. Maybe that has changed and all CompSci teachers now mandate initializing all variables in all programs in all languages. However, that kind of proves that this choice is rather arbitrary and more a function of "style".
I looked for, but do not seem to have access to, the internal PHP discussions generated by that RFC, so I cannot know what arguments people were using on either side. I know what my main argument is: prove to me it's better, or safer, or any of the other condescending descriptors used in favor of banning UVs/UAIs. I have not been able to find a single concrete example of how UVs actually achieve this level of devilish behavior that will bring down the entire internet if left as notices instead of warnings. I would love to see some sample code a real, half-competent programmer would use that could result in a security hole. I can assure you that not one single program I've written in 30 years of script-language usage suffers from a bug caused by this. To bastardize Jerry McGuire: Show Me The Bugs!
I would guess/hope a competent programmer would think like I do (and the original creators of PHP clearly did), and at every point they are going to use a variable (that they aren't staring at a previous use of on the same code page/scope) they say to themselves "this variable might be unset". The base assumption is *always* the variable is unset. Further, if you stick with the general paradigm that a value of 0 in your program is a negative indication (as is false, null, etc.) then unset is just as good! That is the precise reason one uses an untyped/loose-typed language! The language does the work of following its rules to massage $x into the form needed for if(!$x) or ++$x!
I've been told often in situations like this that "not all programmers are competent" and so need such "hand holding" to protect themselves. I can understand that point, but why should it be *forced* on all of the competent programmers? Why are we *forcing* the lowest common denominator? Why aren't we allowing people and projects that have such people or needs to turn on a configuration option (or even make it the default)? Why don't we give those who don't need their hands held the option to stick with the multi-decade status quo? Perl did. Even insane-for-backwards-compatibility python did not institute a change between v2 and v3 that required changes to 5-20% of a codebase! At the bottom of the "I know better", "hold their hands" slope lies Logo. That is not useful to me.
I have a few personal philosophies. One is "always forward, never back", especially when it comes to computers. I still use many perl scripts I wrote in 1992+ and haven't modified since. I use many others that required a line or two changed once in a while when the OS upgraded; in perl, php, python, js, etc. Same reason I use Linux/XFCE/sawfish instead of Windows or GNOME. If I'm going to spend a day coding or configuring, it's going to be to get something new done (i.e. make a new program) that will move me forward and build on my past efforts, not fighting with some arbitrary change foisted upon me that breaks everything in a horrific manner just to get me back to where I was yesterday! Those types of OSs and languages and software I expelled from my life ages ago. When PHP makes UV/UAI a runtime error, it will be the first time PHP has broken my rule, out of 23 years. (Perl has never broken this rule, out of 30+ years.)
Register_globals makes for an interesting comparison. It was on by default, encouraged, and used everywhere until, what, PHP5 (or 4)? That feature has plainly obvious and trivial examples as to why it can be a risk and a security hole. In fact, the thing that made it a risk is precisely that it broke the promise that a var you didn't initialize was going to be unset. You had no clue what any random $identifier was going to contain, because it was externally controlled. The fact that the feature was killed like a decade ago proves it was a massively bigger risk than UV/UAI is now.
So what about the fix/mitigation/pain aspect? Well, that was easy/quick relative to the mess UV/UAI causes. Just look at the handful of get/post (and cookie) vars your page expects (something that can be grepped!) and change them to $_GET[], et al, or "init" them yourself at the top with $expected=$_GET['expected']. A handful of lines to edit with a very low probability of introducing bugs. I remember when I had to do this to every script I ever wrote and it was quick and easy and painless. So the overall equation of minimizing risk vs the pain of the solution was extremely favorable. Now apply that same calculation to UV/UAI. I challenge you to illustrate for me that the two variables of the equation are similar to the register_globals situation.
Likewise, I was appalled, and then relieved when the PHP devs said they wanted to get rid of <? ?> short tags but decided against it. It's very similar to the UV/UAI issue because it's a solution in search of a problem, something that has been used since day 1, actively encouraged, and the risk/pain equation is horrifically lopsided. And at least that problem can be grepped! UAI really cannot. That <? ?> came as close as it did to being deprecated/errored indicates that there is a real problem with the PHP leadership/voters' mindset where many really don't care at all about existing codebases or valuable programmer time.
I disagree with your characterization of the 36 who voted in favour of an error exception as tyrants, though I do agree it would have been a step too far. [...] notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
You agree it's a "step too far" but then hint in the second part what we all know is coming: one day (soon) PHP devs will change UV into a full blown error. I bet many are itching to make UAI one too! Give it a few extra years.
However, I won't be crying, because I can, and will, tweak a few lines of PHP source code and compile my own (rpm tools on RH-based systems make this exceptionally easy). I've decided UV/UAI is insanity, especially if no one can explain how this is even a small security hole for *me*, and the path of least pain with equal gain is to maintain my own version, perhaps called "sane-php" or "freedom-php".
I know for a fact I won't be the only one. UV/UAI and <? ?> nonsense is precisely what prompts people to flee a project, or fork. The reason there's not an uproar yet is that (some estimates) have PHP8 usage at only around 1% at the moment. Just wait until RHEL ships it by default and all the LTS Deb/Ubuntus with PHP7 go EOL. Heck, even Fedora had to delay PHP8 2 or 3 releases vs planned because it caused so much grief.
One more thought: this UV/UAI "fix" could actually cause more security holes and less attention to notices/warnings overall because, as of now, the easy fix is to disable logging of warnings. If your site gets reams of traffic, you'll practically be forced to go ~E_WARNING, otherwise your log disks will fill up and you'll kill your SSD lifespan. That will cause "real" warnings (which I do want to see!) to go completely unnoticed. How is that a better result? I won't be the only one... It'll make dev a disaster because on a dev box, which will have display_errors=on, I won't see any of the egregious warnings in-page, making bug-free development that much harder. If the goal is to get more attention to warnings/notices, UV/UAI might actually do the opposite.
php > error_reporting(\E_ALL); php > $v = ["ook", "eek"]; php > [$ook, $eek, $ack] = $v; PHP Warning: Undefined array key 2 in php shell code on line 1
That notices have historically been hidden does not excuse you from checking your inputs and/or correcting them where needed.
What if the function returns 2 values in some cases, and 3 in others? Yes, that might not be a great design choice, but it's a legitimate one in that it can be logically correct. You are punishing the caller with a warning for a design choice inside the function (they may not have written). And you've given them no way work around it without a whole whack of extra, ugly lines of ?? or isset on a temporary result array variable. All that pain for what gain? Show me the security hole.
I'll grant you that dealing with undefined array indices used to be kind of awkward, such that you had to pepper your code with a lot of isset() or array_key_exists() (depending on whether null is an expected value for an array member), but that's nevertheless what you had to do to have robust logic.
Why? As above, prove it's "robust" vs the alternative. The RFC and random forum/bug discussions I've seen about this do nothing but bandy about the condescending descriptors with nary a shred of evidence of said "unrobustness".
No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP?
In my opinion you proceed from a false assumption. As I stated above, accessing an undefined variable has always been an error (at least since PHP 4, if not earlier), albeit a putatively mild one. It is now merely less-mild.
What is the false assumption? It is irrelevant that they made it a "notice" in PHP2, 3, 4 or 5, and a warning in 8. The main problem, which you don't address, is the freedom to choose. Why can't we have that freedom? Why do the 36 get to choose for the world and why do they seem so uniquely oblivious to existing codebases? I always thought python was bad, but at least they admit, that by design, they will screw you over every major release and always have!
We are not talking about a change that allows the PHP language developers to rip out thousands of C lines of cruft or make the language perform 30% faster. We are talking about, I'm guessing, 1 to 10 lines of C code changed and 0% speedup. All for what?
Again, I sympathize since you're dealing with an old code-base. I nevertheless believe you've been doing things wrong by treating notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
I always code perl with -w on, but strict off. That's the equivalent of seeing all notices/warnings in PHP. In the olden days of PHP I'd log E_ALL because only "sane" things were warnings... kind of like perl. I don't know where along the way I ~E_NOTICEd, but over the years PHP has made enough non-problems into notices that, yes, I completely ignore notices now. Unlike in perl, they don't seem to ever match up with an "oopsy" moment: they simply moan about reams of style choices that I disagree with.
I trusted the PHP devs to make good decisions as to what they were going to warn or deprecate, and I really have agreed with their choices on everything... until now. Now it feels like they've jumped on the "change for change's sake" bandwagon like some other FLOSS projects; or worse, the "our style is right and you'll like it" attitude. But at least most of those other projects, if forced to still use them, provided some gravy! There is zero upside *for me* for the PHP UV/UAI changes.
Since I have no logic error or security hole in my program because of UV/UAI, the only "doing things wrong" I've done is to trust that the PHP braintrust will keep making sane choices and/or maintain my freedom to choose.
I will end with a lame appeal to authority, but one that is meaningful to me as a longtime fan: Rasmus Lerdorf, inventor of PHP, UV vote "keep notice", UAI vote: "keep notice". Rasmus gets it. (Oh ya, and Linus would never allow a change like this in the Linux Kernel without massively obvious and good reasons. And...)
APPENDIX:
Example #0:
function Foo { while ( ... ) if (!$i++) {} }
Is a perfectly reasonable/concise, if lazy, paradigm for detecting the first time in a loop and keeping a count of iterations as a bonus. This is now a warning in PHP8. Is anything at all gained by putting "$i=0" before the while, maybe at the top of the page or the start of a function? If I wanted to be forced to do that, I'd be using a language that wants me to. And even if one thinks i=0 should be required, it's not universal, as perl happily accepts that without warning even with warnings on! perl sees that and says "the programmer has his big boy boots on and does not need coddling". Even with strict on, as long as you declared it with my($i) (even without initializing it!) perl doesn't complain.
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
-- John Lange
I don’t really have a horse in this race, but I think John make one factual error. It’s minor and doesn’t change his point, but: if(!i++) { ... } is perfectly valid in C, where 0==false. It’s equivalent to (I think…): if(i==0) { i++; ... } else { i++; ... }; IIRC, C has the comma operator, albeit thankfully rarely used, so if you really wanted to do this, I think it could be slightly better written: if(i==0, i++) { ... } I could be wrong, I haven’t attempted to write C code in 25+ years. It’s not something you would want to see, but you certainly could. FWIW, I agree with both sides in the original debate: PHP’s ultra-weak typing and initialization lay pervasive traps for programmers, whether they be incompetent, lazy, tired, or merely distracted. (And based on my lived experience, the overwhelming majority of programmers – nay, *people* in general – are NOT “highly competent”: they’re “good enough”. But at the same time, this is a seemingly-gratuitous language change that reminds me VERY strongly of system all of a sudden being shoved down everyone’s throats, even though systemd introduces some good features that were previously lacking. And list($a,$b,$c)=… is a useful notation in PHP. Perhaps this is like Perl 6, where it’s nearly a completely different language from the previous version, sharing the name and basic syntax? But at least there’s still a team patching security holes in Perl 5. I have no confidence that would happen with PHP. -Adam From: Roundtable <roundtable-bounces@muug.ca> On Behalf Of John Lange Sent: Thursday, January 13, 2022 2:18 PM To: Continuation of Round Table discussion <roundtable@muug.ca> Subject: Re: [RndTbl] PHP undefined vars / array indices As a former professional PHP programmer and current hobbyist programmer (not in PHP though), I agree with Trevor. (disclaimer: I did not go back and re-read all the PHP threads on this topic). PHP made a fundamental change to the way the language works which breaks backwards compatibility and has not provided any concrete evidence that supports the published justification for this change. "style" and "best practice" really are just opinions. I also don't see any reason why PHP could not have defined a global "use_strict= true/false" parameter similar to the approach that Perl took years back. The default could even be "true", if they want to emphasize the importance of it. However, I do agree that it's not good programming practice. Consider this example: function Foo { while ( $i < 5 ) if (!$i++) {} // ... (a whole bunch more lines of code go here) .. while ( $i < 5 ) // inadvertently using the same variable because $i is your favorite 'counter' and you forgot you already used it if (!$i++) { } // This line never runs } On a side note, you would only ever see "!$i++" syntax in non-declarative languages like PHP. It makes no sense otherwise since integers can never be false. Aside from that, my personal preference is to code for readability and I find the statement is hard to interpret. So I prefer: If ($i == false) { $i++ ... other stuff } But never the less the point is I agree that PHP should not have broken backward compatibility. By doing so it will force many sites to remain on PHP 7.x thereby opening up the very real possibility that a 7.x security vulnerability will get exploited and cause mass-grief (log4j anyone?). John On Thu, Jan 13, 2022 at 3:04 AM Trevor Cordes <trevor@tecnopolis.ca<mailto:trevor@tecnopolis.ca>> wrote: On 2022-01-10 J. King wrote:
I sympathize with your plight as you're dealing with an older code-
Thank you for your constructive and well-reasoned reply. It is nice to have another person to discuss this important issue with. (I apologize in advance for the length of this reply.) I think it's helpful to dissect the issue into three parts: the risk posed by the original status quo, and the pain of change, and the freedom of the programmer. In advance, I will readily grant that the uninitialized value (UV) problem is more often a possible "mistake" than the uninitialized array index (UAI) one. I would also guess it is much more rare. At least that is what my attempts to "fix" my code has revealed. But everything I discuss applies pretty much equally to both. And the PHP8 RFC, though it separated the issues, ended up lumping them into the same result: turning them both into warnings. Thus it follows that the arguments used to vilify one (UV) must closely or somewhat apply to the other (UAI). I've been using PHP (in production) since 1999 and v3. I'm nearly positive UV and UAIs were not even a notice back then. In fact, with the (yes, evil) register_globals they got rid of a long time ago (more below), the whole idea of knowing if a var was initialized or not was impossible (without jumping through the isset hoops which almost nobody did, especially since ?? didn't yet exist). So let's establish that PHP from v1 through v3 not only didn't care, it kind of mandated the programmer not check for uninitialized variables (UV). In other words, it not only said it was "ok", it said "this is the way it's done". I can go into any of my ancient PHP3 books (from many various publishers) and guarantee you I will not find one example that bothers to initialize a variable when there was no reason to. (See example #0 at bottom.) And that's ok, because many other loose, untyped, scripting languages that were popular around 1999 were exactly the same way (e.g. perl). In fact, I would posit that they were designed this way! It wasn't an oversight or laziness: it was the desire to have the programming language do more of the work for you, and to reduce the code line count (vs C) required to get a job done (hence why the scripting languages were considered "rapid" and (often) "prototype"). Were the developers of PHP in 1999 ignorant? Or were they trying to create a language suited for a purpose in a way that was similar to its peers and required "less work" than the heavy alternatives? So what's really the problem here? All I hear from the "pro" side is "times have changed", "it's not good practice", "it's not robust", "legacy", "possible logic errors", "doing things wrong". And they are saying the original makers of PHP, all the book authors from back then, and a generation of programmers who used it that way were/are wrong and must change (certainly by the time the "warning" is turned into a runtime error). OK, someone could have that opinion, I get it, especially someone using PHP for less than 5-10 years. But before they make me change 20k+ actual lines of code to make it uglier and less readable (IMO) they better have some really good, concrete arguments. The onus should be on the ones making the sweeping changes. As an aside, I have a B.Sc in CompSci (around the Java era, though I rarely used Java) and took every major related course, learning about 10 languages. Not once was I told I had to "initialize my variables", and certainly not check for UAI. Not once did I lose a mark for not doing so. If the language being used required it, then you did it. If it didn't, then all that mattered was having a correct, readable program. Maybe that has changed and all CompSci teachers now mandate initializing all variables in all programs in all languages. However, that kind of proves that this choice is rather arbitrary and more a function of "style". I looked for, but do not seem to have access to, the internal PHP discussions generated by that RFC, so I cannot know what arguments people were using on either side. I know what my main argument is: prove to me it's better, or safer, or any of the other condescending descriptors used in favor of banning UVs/UAIs. I have not been able to find a single concrete example of how UVs actually achieve this level of devilish behavior that will bring down the entire internet if left as notices instead of warnings. I would love to see some sample code a real, half-competent programmer would use that could result in a security hole. I can assure you that not one single program I've written in 30 years of script-language usage suffers from a bug caused by this. To bastardize Jerry McGuire: Show Me The Bugs! I would guess/hope a competent programmer would think like I do (and the original creators of PHP clearly did), and at every point they are going to use a variable (that they aren't staring at a previous use of on the same code page/scope) they say to themselves "this variable might be unset". The base assumption is *always* the variable is unset. Further, if you stick with the general paradigm that a value of 0 in your program is a negative indication (as is false, null, etc.) then unset is just as good! That is the precise reason one uses an untyped/loose-typed language! The language does the work of following its rules to massage $x into the form needed for if(!$x) or ++$x! I've been told often in situations like this that "not all programmers are competent" and so need such "hand holding" to protect themselves. I can understand that point, but why should it be *forced* on all of the competent programmers? Why are we *forcing* the lowest common denominator? Why aren't we allowing people and projects that have such people or needs to turn on a configuration option (or even make it the default)? Why don't we give those who don't need their hands held the option to stick with the multi-decade status quo? Perl did. Even insane-for-backwards-compatibility python did not institute a change between v2 and v3 that required changes to 5-20% of a codebase! At the bottom of the "I know better", "hold their hands" slope lies Logo. That is not useful to me. I have a few personal philosophies. One is "always forward, never back", especially when it comes to computers. I still use many perl scripts I wrote in 1992+ and haven't modified since. I use many others that required a line or two changed once in a while when the OS upgraded; in perl, php, python, js, etc. Same reason I use Linux/XFCE/sawfish instead of Windows or GNOME. If I'm going to spend a day coding or configuring, it's going to be to get something new done (i.e. make a new program) that will move me forward and build on my past efforts, not fighting with some arbitrary change foisted upon me that breaks everything in a horrific manner just to get me back to where I was yesterday! Those types of OSs and languages and software I expelled from my life ages ago. When PHP makes UV/UAI a runtime error, it will be the first time PHP has broken my rule, out of 23 years. (Perl has never broken this rule, out of 30+ years.) Register_globals makes for an interesting comparison. It was on by default, encouraged, and used everywhere until, what, PHP5 (or 4)? That feature has plainly obvious and trivial examples as to why it can be a risk and a security hole. In fact, the thing that made it a risk is precisely that it broke the promise that a var you didn't initialize was going to be unset. You had no clue what any random $identifier was going to contain, because it was externally controlled. The fact that the feature was killed like a decade ago proves it was a massively bigger risk than UV/UAI is now. So what about the fix/mitigation/pain aspect? Well, that was easy/quick relative to the mess UV/UAI causes. Just look at the handful of get/post (and cookie) vars your page expects (something that can be grepped!) and change them to $_GET[], et al, or "init" them yourself at the top with $expected=$_GET['expected']. A handful of lines to edit with a very low probability of introducing bugs. I remember when I had to do this to every script I ever wrote and it was quick and easy and painless. So the overall equation of minimizing risk vs the pain of the solution was extremely favorable. Now apply that same calculation to UV/UAI. I challenge you to illustrate for me that the two variables of the equation are similar to the register_globals situation. Likewise, I was appalled, and then relieved when the PHP devs said they wanted to get rid of <? ?> short tags but decided against it. It's very similar to the UV/UAI issue because it's a solution in search of a problem, something that has been used since day 1, actively encouraged, and the risk/pain equation is horrifically lopsided. And at least that problem can be grepped! UAI really cannot. That <? ?> came as close as it did to being deprecated/errored indicates that there is a real problem with the PHP leadership/voters' mindset where many really don't care at all about existing codebases or valuable programmer time.
I disagree with your characterization of the 36 who voted in favour of an error exception as tyrants, though I do agree it would have been a step too far. [...] notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
You agree it's a "step too far" but then hint in the second part what we all know is coming: one day (soon) PHP devs will change UV into a full blown error. I bet many are itching to make UAI one too! Give it a few extra years. However, I won't be crying, because I can, and will, tweak a few lines of PHP source code and compile my own (rpm tools on RH-based systems make this exceptionally easy). I've decided UV/UAI is insanity, especially if no one can explain how this is even a small security hole for *me*, and the path of least pain with equal gain is to maintain my own version, perhaps called "sane-php" or "freedom-php". I know for a fact I won't be the only one. UV/UAI and <? ?> nonsense is precisely what prompts people to flee a project, or fork. The reason there's not an uproar yet is that (some estimates) have PHP8 usage at only around 1% at the moment. Just wait until RHEL ships it by default and all the LTS Deb/Ubuntus with PHP7 go EOL. Heck, even Fedora had to delay PHP8 2 or 3 releases vs planned because it caused so much grief. One more thought: this UV/UAI "fix" could actually cause more security holes and less attention to notices/warnings overall because, as of now, the easy fix is to disable logging of warnings. If your site gets reams of traffic, you'll practically be forced to go ~E_WARNING, otherwise your log disks will fill up and you'll kill your SSD lifespan. That will cause "real" warnings (which I do want to see!) to go completely unnoticed. How is that a better result? I won't be the only one... It'll make dev a disaster because on a dev box, which will have display_errors=on, I won't see any of the egregious warnings in-page, making bug-free development that much harder. If the goal is to get more attention to warnings/notices, UV/UAI might actually do the opposite.
php > error_reporting(\E_ALL); php > $v = ["ook", "eek"]; php > [$ook, $eek, $ack] = $v; PHP Warning: Undefined array key 2 in php shell code on line 1
That notices have historically been hidden does not excuse you from checking your inputs and/or correcting them where needed.
What if the function returns 2 values in some cases, and 3 in others? Yes, that might not be a great design choice, but it's a legitimate one in that it can be logically correct. You are punishing the caller with a warning for a design choice inside the function (they may not have written). And you've given them no way work around it without a whole whack of extra, ugly lines of ?? or isset on a temporary result array variable. All that pain for what gain? Show me the security hole.
I'll grant you that dealing with undefined array indices used to be kind of awkward, such that you had to pepper your code with a lot of isset() or array_key_exists() (depending on whether null is an expected value for an array member), but that's nevertheless what you had to do to have robust logic.
Why? As above, prove it's "robust" vs the alternative. The RFC and random forum/bug discussions I've seen about this do nothing but bandy about the condescending descriptors with nary a shred of evidence of said "unrobustness".
No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP?
In my opinion you proceed from a false assumption. As I stated above, accessing an undefined variable has always been an error (at least since PHP 4, if not earlier), albeit a putatively mild one. It is now merely less-mild.
What is the false assumption? It is irrelevant that they made it a "notice" in PHP2, 3, 4 or 5, and a warning in 8. The main problem, which you don't address, is the freedom to choose. Why can't we have that freedom? Why do the 36 get to choose for the world and why do they seem so uniquely oblivious to existing codebases? I always thought python was bad, but at least they admit, that by design, they will screw you over every major release and always have! We are not talking about a change that allows the PHP language developers to rip out thousands of C lines of cruft or make the language perform 30% faster. We are talking about, I'm guessing, 1 to 10 lines of C code changed and 0% speedup. All for what?
Again, I sympathize since you're dealing with an old code-base. I nevertheless believe you've been doing things wrong by treating notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
I always code perl with -w on, but strict off. That's the equivalent of seeing all notices/warnings in PHP. In the olden days of PHP I'd log E_ALL because only "sane" things were warnings... kind of like perl. I don't know where along the way I ~E_NOTICEd, but over the years PHP has made enough non-problems into notices that, yes, I completely ignore notices now. Unlike in perl, they don't seem to ever match up with an "oopsy" moment: they simply moan about reams of style choices that I disagree with. I trusted the PHP devs to make good decisions as to what they were going to warn or deprecate, and I really have agreed with their choices on everything... until now. Now it feels like they've jumped on the "change for change's sake" bandwagon like some other FLOSS projects; or worse, the "our style is right and you'll like it" attitude. But at least most of those other projects, if forced to still use them, provided some gravy! There is zero upside *for me* for the PHP UV/UAI changes. Since I have no logic error or security hole in my program because of UV/UAI, the only "doing things wrong" I've done is to trust that the PHP braintrust will keep making sane choices and/or maintain my freedom to choose. I will end with a lame appeal to authority, but one that is meaningful to me as a longtime fan: Rasmus Lerdorf, inventor of PHP, UV vote "keep notice", UAI vote: "keep notice". Rasmus gets it. (Oh ya, and Linus would never allow a change like this in the Linux Kernel without massively obvious and good reasons. And...) APPENDIX: Example #0: function Foo { while ( ... ) if (!$i++) {} } Is a perfectly reasonable/concise, if lazy, paradigm for detecting the first time in a loop and keeping a count of iterations as a bonus. This is now a warning in PHP8. Is anything at all gained by putting "$i=0" before the while, maybe at the top of the page or the start of a function? If I wanted to be forced to do that, I'd be using a language that wants me to. And even if one thinks i=0 should be required, it's not universal, as perl happily accepts that without warning even with warnings on! perl sees that and says "the programmer has his big boy boots on and does not need coddling". Even with strict on, as long as you declared it with my($i) (even without initializing it!) perl doesn't complain. _______________________________________________ Roundtable mailing list Roundtable@muug.ca<mailto:Roundtable@muug.ca> https://muug.ca/mailman/listinfo/roundtable -- John Lange
Thanks for the correction Adam (and btw, it's also valid in C++). So I should have said "*you would only ever see "!$i++" syntax in weakly-typed languages*". And also, I should never say never... John On Thu, Jan 13, 2022 at 4:33 PM Adam Thompson <athompso@athompso.net> wrote:
I don’t really have a horse in this race, but I think John make one factual error. It’s minor and doesn’t change his point, but:
if(!i++) { ... }
is perfectly valid in C, where 0==false. It’s equivalent to (I think…):
if(i==0) { i++; ... } else { i++; ... };
IIRC, C has the comma operator, albeit thankfully rarely used, so if you really wanted to do this, I think it could be slightly better written:
if(i==0, i++) { ... }
I could be wrong, I haven’t attempted to write C code in 25+ years. It’s not something you would want to see, but you certainly *could*.
FWIW, I agree with both sides in the original debate: PHP’s ultra-weak typing and initialization lay pervasive traps for programmers, whether they be incompetent, lazy, tired, or merely distracted. (And based on my lived experience, the overwhelming majority of programmers – nay, **people** in general – are NOT “highly competent”: they’re “good enough”. But at the same time, this is a seemingly-gratuitous language change that reminds me VERY strongly of system all of a sudden being shoved down everyone’s throats, even though systemd introduces some good features that were previously lacking. And list($a,$b,$c)=… is a useful notation in PHP.
Perhaps this is like Perl 6, where it’s nearly a completely different language from the previous version, sharing the name and basic syntax? But at least there’s still a team patching security holes in Perl 5. I have no confidence that would happen with PHP.
-Adam
*From:* Roundtable <roundtable-bounces@muug.ca> *On Behalf Of *John Lange *Sent:* Thursday, January 13, 2022 2:18 PM *To:* Continuation of Round Table discussion <roundtable@muug.ca> *Subject:* Re: [RndTbl] PHP undefined vars / array indices
As a former professional PHP programmer and current hobbyist programmer (not in PHP though), I agree with Trevor. (disclaimer: I did not go back and re-read all the PHP threads on this topic).
PHP made a fundamental change to the way the language works which breaks backwards compatibility and has not provided any concrete evidence that supports the published justification for this change. "style" and "best practice" really are just opinions.
I also don't see any reason why PHP could not have defined a global "use_strict= true/false" parameter similar to the approach that Perl took years back. The default could even be "true", if they want to emphasize the importance of it.
However, I do agree that it's not good programming practice. Consider this example:
function Foo { while ( $i < 5 ) if (!$i++) {}
// ... (a whole bunch more lines of code go here) ..
while ( $i < 5 ) // inadvertently using the same variable because $i is your favorite 'counter' and you forgot you already used it if (!$i++) { } // This line never runs
}
On a side note, you would only ever see "!$i++" syntax in non-declarative languages like PHP. It makes no sense otherwise since integers can never be false. Aside from that, my personal preference is to code for readability and I find the statement is hard to interpret. So I prefer:
If ($i == false) {
$i++
... other stuff
}
But never the less the point is I agree that PHP should not have broken backward compatibility. By doing so it will force many sites to remain on PHP 7.x thereby opening up the very real possibility that a 7.x security vulnerability will get exploited and cause mass-grief (log4j anyone?).
John
On Thu, Jan 13, 2022 at 3:04 AM Trevor Cordes <trevor@tecnopolis.ca> wrote:
On 2022-01-10 J. King wrote:
I sympathize with your plight as you're dealing with an older code-
Thank you for your constructive and well-reasoned reply. It is nice to have another person to discuss this important issue with. (I apologize in advance for the length of this reply.)
I think it's helpful to dissect the issue into three parts: the risk posed by the original status quo, and the pain of change, and the freedom of the programmer. In advance, I will readily grant that the uninitialized value (UV) problem is more often a possible "mistake" than the uninitialized array index (UAI) one. I would also guess it is much more rare. At least that is what my attempts to "fix" my code has revealed. But everything I discuss applies pretty much equally to both. And the PHP8 RFC, though it separated the issues, ended up lumping them into the same result: turning them both into warnings. Thus it follows that the arguments used to vilify one (UV) must closely or somewhat apply to the other (UAI).
I've been using PHP (in production) since 1999 and v3. I'm nearly positive UV and UAIs were not even a notice back then. In fact, with the (yes, evil) register_globals they got rid of a long time ago (more below), the whole idea of knowing if a var was initialized or not was impossible (without jumping through the isset hoops which almost nobody did, especially since ?? didn't yet exist).
So let's establish that PHP from v1 through v3 not only didn't care, it kind of mandated the programmer not check for uninitialized variables (UV). In other words, it not only said it was "ok", it said "this is the way it's done". I can go into any of my ancient PHP3 books (from many various publishers) and guarantee you I will not find one example that bothers to initialize a variable when there was no reason to. (See example #0 at bottom.)
And that's ok, because many other loose, untyped, scripting languages that were popular around 1999 were exactly the same way (e.g. perl). In fact, I would posit that they were designed this way! It wasn't an oversight or laziness: it was the desire to have the programming language do more of the work for you, and to reduce the code line count (vs C) required to get a job done (hence why the scripting languages were considered "rapid" and (often) "prototype").
Were the developers of PHP in 1999 ignorant? Or were they trying to create a language suited for a purpose in a way that was similar to its peers and required "less work" than the heavy alternatives?
So what's really the problem here? All I hear from the "pro" side is "times have changed", "it's not good practice", "it's not robust", "legacy", "possible logic errors", "doing things wrong". And they are saying the original makers of PHP, all the book authors from back then, and a generation of programmers who used it that way were/are wrong and must change (certainly by the time the "warning" is turned into a runtime error). OK, someone could have that opinion, I get it, especially someone using PHP for less than 5-10 years. But before they make me change 20k+ actual lines of code to make it uglier and less readable (IMO) they better have some really good, concrete arguments. The onus should be on the ones making the sweeping changes.
As an aside, I have a B.Sc in CompSci (around the Java era, though I rarely used Java) and took every major related course, learning about 10 languages. Not once was I told I had to "initialize my variables", and certainly not check for UAI. Not once did I lose a mark for not doing so. If the language being used required it, then you did it. If it didn't, then all that mattered was having a correct, readable program. Maybe that has changed and all CompSci teachers now mandate initializing all variables in all programs in all languages. However, that kind of proves that this choice is rather arbitrary and more a function of "style".
I looked for, but do not seem to have access to, the internal PHP discussions generated by that RFC, so I cannot know what arguments people were using on either side. I know what my main argument is: prove to me it's better, or safer, or any of the other condescending descriptors used in favor of banning UVs/UAIs. I have not been able to find a single concrete example of how UVs actually achieve this level of devilish behavior that will bring down the entire internet if left as notices instead of warnings. I would love to see some sample code a real, half-competent programmer would use that could result in a security hole. I can assure you that not one single program I've written in 30 years of script-language usage suffers from a bug caused by this. To bastardize Jerry McGuire: Show Me The Bugs!
I would guess/hope a competent programmer would think like I do (and the original creators of PHP clearly did), and at every point they are going to use a variable (that they aren't staring at a previous use of on the same code page/scope) they say to themselves "this variable might be unset". The base assumption is *always* the variable is unset. Further, if you stick with the general paradigm that a value of 0 in your program is a negative indication (as is false, null, etc.) then unset is just as good! That is the precise reason one uses an untyped/loose-typed language! The language does the work of following its rules to massage $x into the form needed for if(!$x) or ++$x!
I've been told often in situations like this that "not all programmers are competent" and so need such "hand holding" to protect themselves. I can understand that point, but why should it be *forced* on all of the competent programmers? Why are we *forcing* the lowest common denominator? Why aren't we allowing people and projects that have such people or needs to turn on a configuration option (or even make it the default)? Why don't we give those who don't need their hands held the option to stick with the multi-decade status quo? Perl did. Even insane-for-backwards-compatibility python did not institute a change between v2 and v3 that required changes to 5-20% of a codebase! At the bottom of the "I know better", "hold their hands" slope lies Logo. That is not useful to me.
I have a few personal philosophies. One is "always forward, never back", especially when it comes to computers. I still use many perl scripts I wrote in 1992+ and haven't modified since. I use many others that required a line or two changed once in a while when the OS upgraded; in perl, php, python, js, etc. Same reason I use Linux/XFCE/sawfish instead of Windows or GNOME. If I'm going to spend a day coding or configuring, it's going to be to get something new done (i.e. make a new program) that will move me forward and build on my past efforts, not fighting with some arbitrary change foisted upon me that breaks everything in a horrific manner just to get me back to where I was yesterday! Those types of OSs and languages and software I expelled from my life ages ago. When PHP makes UV/UAI a runtime error, it will be the first time PHP has broken my rule, out of 23 years. (Perl has never broken this rule, out of 30+ years.)
Register_globals makes for an interesting comparison. It was on by default, encouraged, and used everywhere until, what, PHP5 (or 4)? That feature has plainly obvious and trivial examples as to why it can be a risk and a security hole. In fact, the thing that made it a risk is precisely that it broke the promise that a var you didn't initialize was going to be unset. You had no clue what any random $identifier was going to contain, because it was externally controlled. The fact that the feature was killed like a decade ago proves it was a massively bigger risk than UV/UAI is now.
So what about the fix/mitigation/pain aspect? Well, that was easy/quick relative to the mess UV/UAI causes. Just look at the handful of get/post (and cookie) vars your page expects (something that can be grepped!) and change them to $_GET[], et al, or "init" them yourself at the top with $expected=$_GET['expected']. A handful of lines to edit with a very low probability of introducing bugs. I remember when I had to do this to every script I ever wrote and it was quick and easy and painless. So the overall equation of minimizing risk vs the pain of the solution was extremely favorable. Now apply that same calculation to UV/UAI. I challenge you to illustrate for me that the two variables of the equation are similar to the register_globals situation.
Likewise, I was appalled, and then relieved when the PHP devs said they wanted to get rid of <? ?> short tags but decided against it. It's very similar to the UV/UAI issue because it's a solution in search of a problem, something that has been used since day 1, actively encouraged, and the risk/pain equation is horrifically lopsided. And at least that problem can be grepped! UAI really cannot. That <? ?> came as close as it did to being deprecated/errored indicates that there is a real problem with the PHP leadership/voters' mindset where many really don't care at all about existing codebases or valuable programmer time.
I disagree with your characterization of the 36 who voted in favour of an error exception as tyrants, though I do agree it would have been a step too far. [...] notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
You agree it's a "step too far" but then hint in the second part what we all know is coming: one day (soon) PHP devs will change UV into a full blown error. I bet many are itching to make UAI one too! Give it a few extra years.
However, I won't be crying, because I can, and will, tweak a few lines of PHP source code and compile my own (rpm tools on RH-based systems make this exceptionally easy). I've decided UV/UAI is insanity, especially if no one can explain how this is even a small security hole for *me*, and the path of least pain with equal gain is to maintain my own version, perhaps called "sane-php" or "freedom-php".
I know for a fact I won't be the only one. UV/UAI and <? ?> nonsense is precisely what prompts people to flee a project, or fork. The reason there's not an uproar yet is that (some estimates) have PHP8 usage at only around 1% at the moment. Just wait until RHEL ships it by default and all the LTS Deb/Ubuntus with PHP7 go EOL. Heck, even Fedora had to delay PHP8 2 or 3 releases vs planned because it caused so much grief.
One more thought: this UV/UAI "fix" could actually cause more security holes and less attention to notices/warnings overall because, as of now, the easy fix is to disable logging of warnings. If your site gets reams of traffic, you'll practically be forced to go ~E_WARNING, otherwise your log disks will fill up and you'll kill your SSD lifespan. That will cause "real" warnings (which I do want to see!) to go completely unnoticed. How is that a better result? I won't be the only one... It'll make dev a disaster because on a dev box, which will have display_errors=on, I won't see any of the egregious warnings in-page, making bug-free development that much harder. If the goal is to get more attention to warnings/notices, UV/UAI might actually do the opposite.
php > error_reporting(\E_ALL); php > $v = ["ook", "eek"]; php > [$ook, $eek, $ack] = $v; PHP Warning: Undefined array key 2 in php shell code on line 1
That notices have historically been hidden does not excuse you from checking your inputs and/or correcting them where needed.
What if the function returns 2 values in some cases, and 3 in others? Yes, that might not be a great design choice, but it's a legitimate one in that it can be logically correct. You are punishing the caller with a warning for a design choice inside the function (they may not have written). And you've given them no way work around it without a whole whack of extra, ugly lines of ?? or isset on a temporary result array variable. All that pain for what gain? Show me the security hole.
I'll grant you that dealing with undefined array indices used to be kind of awkward, such that you had to pepper your code with a lot of isset() or array_key_exists() (depending on whether null is an expected value for an array member), but that's nevertheless what you had to do to have robust logic.
Why? As above, prove it's "robust" vs the alternative. The RFC and random forum/bug discussions I've seen about this do nothing but bandy about the condescending descriptors with nary a shred of evidence of said "unrobustness".
No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP?
In my opinion you proceed from a false assumption. As I stated above, accessing an undefined variable has always been an error (at least since PHP 4, if not earlier), albeit a putatively mild one. It is now merely less-mild.
What is the false assumption? It is irrelevant that they made it a "notice" in PHP2, 3, 4 or 5, and a warning in 8. The main problem, which you don't address, is the freedom to choose. Why can't we have that freedom? Why do the 36 get to choose for the world and why do they seem so uniquely oblivious to existing codebases? I always thought python was bad, but at least they admit, that by design, they will screw you over every major release and always have!
We are not talking about a change that allows the PHP language developers to rip out thousands of C lines of cruft or make the language perform 30% faster. We are talking about, I'm guessing, 1 to 10 lines of C code changed and 0% speedup. All for what?
Again, I sympathize since you're dealing with an old code-base. I nevertheless believe you've been doing things wrong by treating notices as no big deal, and you're probably setting yourself up for more tears by not adapting now.
I always code perl with -w on, but strict off. That's the equivalent of seeing all notices/warnings in PHP. In the olden days of PHP I'd log E_ALL because only "sane" things were warnings... kind of like perl. I don't know where along the way I ~E_NOTICEd, but over the years PHP has made enough non-problems into notices that, yes, I completely ignore notices now. Unlike in perl, they don't seem to ever match up with an "oopsy" moment: they simply moan about reams of style choices that I disagree with.
I trusted the PHP devs to make good decisions as to what they were going to warn or deprecate, and I really have agreed with their choices on everything... until now. Now it feels like they've jumped on the "change for change's sake" bandwagon like some other FLOSS projects; or worse, the "our style is right and you'll like it" attitude. But at least most of those other projects, if forced to still use them, provided some gravy! There is zero upside *for me* for the PHP UV/UAI changes.
Since I have no logic error or security hole in my program because of UV/UAI, the only "doing things wrong" I've done is to trust that the PHP braintrust will keep making sane choices and/or maintain my freedom to choose.
I will end with a lame appeal to authority, but one that is meaningful to me as a longtime fan: Rasmus Lerdorf, inventor of PHP, UV vote "keep notice", UAI vote: "keep notice". Rasmus gets it. (Oh ya, and Linus would never allow a change like this in the Linux Kernel without massively obvious and good reasons. And...)
APPENDIX:
Example #0:
function Foo { while ( ... ) if (!$i++) {} }
Is a perfectly reasonable/concise, if lazy, paradigm for detecting the first time in a loop and keeping a count of iterations as a bonus. This is now a warning in PHP8. Is anything at all gained by putting "$i=0" before the while, maybe at the top of the page or the start of a function? If I wanted to be forced to do that, I'd be using a language that wants me to. And even if one thinks i=0 should be required, it's not universal, as perl happily accepts that without warning even with warnings on! perl sees that and says "the programmer has his big boy boots on and does not need coddling". Even with strict on, as long as you declared it with my($i) (even without initializing it!) perl doesn't complain.
_______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
--
John Lange _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
-- John Lange
On 2022-01-13 Adam Thompson wrote:
I don’t really have a horse in this race, but I think John make one factual error. It’s minor and doesn’t change his point, but: if(!i++) { ... } is perfectly valid in C, where 0==false. It’s equivalent to (I think…): if(i==0) { i++; ... } else { i++; ... }; IIRC, C has the comma operator, albeit thankfully rarely used, so if you really wanted to do this, I think it could be slightly better written: if(i==0, i++) { ... } I could be wrong, I haven’t attempted to write C code in 25+ years. It’s not something you would want to see, but you certainly could.
Hey, I use comma all the time! :-) Well, when it makes sense. Usually in super long perl-oneliners or to get a lot accomplished in one expression in a perl regex using /e. Perl allows your if(i==0,i++) so I'm nearly positive C would too (Brad, paging Brad...).
But at the same time, this is a seemingly-gratuitous language change that reminds me VERY strongly of system all of a sudden being shoved down everyone’s throats, even though systemd introduces some good features that were previously
Funny, in my discussions with people, systemd came up a lot. But rejigging my systems to "speak systemd" took a few hours for my own box and a few more for all my customers. My main beef with the PHP change is it will literally take me weeks to change, a tough sell to my clients (and myself for my own projects)! And your systemd example is even better because systemd promised (and delivered) on many fine improvements (faster boot, standardized declarative unit files). The pain bought us quite a bit. (Though I still hate systemd and wish it never had been made, but maybe more so because of Lennart at this point than the actual product; oh and the whole "everything creep" thing.) :-)
Perhaps this is like Perl 6, where it’s nearly a completely different language from the previous version, sharing the name and basic syntax? But at least there’s still a team patching security holes in Perl 5. I have no confidence that would happen with PHP. -Adam
Perl 5 is still actively developed. In fact, I do believe it gets more dev attention than 6 ever will. I have never seen 6 code in use in the wild. Ever. As a 30 year perl fan, while I like to read about 6, I have no plans whatsoever to use it in the near or distant future. It's funny, had this discussion with someone too: We all thought Perl botched it with 6. What a disaster was 6! Splitting perl. Changing the language too much, yada yada. But you know what, I think what happened with 6 was the best thing that could have happened! Think about it, had they instead slowly morphed 5 into 6 over the years, making the ton of backwards incompatible changes that would be required, no one would be using 5 *or* 6 right now. Instead they did the best thing possible: have a hard split and make a new language and maintain both. The only mistake they made (IMO) is naming it Perl 6. They should have just come up with a whole new name -- maybe some play on the word Perl. At the rate PHP is moving with the cray cray changes, they'll make a mistake worse than Perl made, and maybe suffer its same loss of popularity. Remember, perl once held the admin/glue title that python now owns. The more I seethe about the PHP change, the more I seriously ponder making my own fork, or my own "unfixed"-version repo, or trying to get a granular logging feature introduced into master project (h/t Richard). The real tell would be if I made a great granular log settings patch (like Node, again h/t Richard) and PHP rejected it because their real goal is to force their style choices on the world (I'd peg that at 50/50 at the moment... or worse).
Which doesn't help this bug at all. Of course, no language can ever tell you you probably meant to add a second $i=0
As a programmer it helps you in 2 ways. First, as a programmer in a declarative language you get used to declaring everything, so when you start to type the second "int $i = 0;" <-- it immediately generates an error in your IDE (if you have one) or a compile time error. Of course, you might forget to declare, so that brings me to point #2. Second, when you are trying to debug why your loop isn't working the first thing you are going to do is look for where this variable is initialized and you immediately realize you screwed up and reused an old variable. Of course our example is extremely simple but imagine a more complex example where $i is modified in a dozen places and perhaps inside some if-then statements are as the result of some other function, e.g. $i = SomeFunctionResult(); I submit that in the non-declarative case you can easily spend a ton of time trying to trace the logic in the lower section of code without realizing your mistake (been there, done that). Regarding Perl6, totally agree it should have been "Perl++". But in IMHO Perl dropped out of favour because of a point I made earlier, it is very often unreadable and therefore hard to learn and maintain. This is made worse by the fact that Perl programmers take pride in writing the most unreadable code possible (there is even a contest for this) and then look down their noses at less "expert" programmers who struggle to understand. This is very ironic given the whole reason interpreted languages were developed in the first place was to make them more "human readable". Congratulations Perl developers! You played yourself! John
On Wednesday, January 19, 2022 9:08:52 A.M. CST John Lange wrote:
I submit that in the non-declarative case you can easily spend a ton of time trying to trace the logic in the lower section of code without realizing your mistake (been there, done that).
At the risk of adding fuel to a fire, I agree with this. I'm a Perl fan myself, and I always add "use strict;" to my code. I appreciate the compiler telling me that it hasn't seen "very_long_variab1e_name" before (did you notice I dropped the changed the "l" to a "1" in "variable"?)
Regarding Perl6, totally agree it should have been "Perl++".
Perl 6 does have a new name now; it was renamed to "Raku" in October 2019: https:// www.raku.org.
But in IMHO Perl dropped out of favour because of a point I made earlier, it is very often unreadable and therefore hard to learn and maintain. This is made worse by the fact that Perl programmers take pride in writing the most unreadable code possible (there is even a contest for this) and then look down their noses at less "expert" programmers who struggle to understand.
Very much this! There's a great temptation in Perl to play "code golf." I admit it feel cools to take a nicely nested if/then/else with a loop and turn it into:
@var = map { condition ? yes : no } sort grep { /regexp/ } @var;
It looks neat and is nice and concise, but maintainable? Not so much. These days I shy away from doing that even in code I write for my own use. Brian
To clear my conscience, I finally have to weigh in with my vote on this topic, which has had a great discussion here! I am an old-school ultra-hard-core algorithmic programmer (M.Sc. CompSci 1975) who absolutely believes in declaring everything, initializing everything before first use, etc. Inconvenience is heavily mitigated with a high-grade programmer's text editor (or a good IDE). I am appalled on a daily basis by the crap programming of Websites I encounter, even at places like Rogers, Fido, Telus/Koodo, Bell, etc., where I would expect to see much better (yeah, I visit those sites on behalf of others who can't even manage their own accounts). The one major exception is the big banks - for the most part, their Websites are functionally still a cut above the rest. The flurry of new "easy" languages we see seems to mainly exist to get people into "programming" who should never be programming anything serious in the first place. That's what produced Cobol ages ago, that's what produced Python, and the trend continues unabated. Hartmut W Sager - Tel +1-204-339-8331 ________________________________ From: Roundtable <roundtable-bounces@muug.ca> on behalf of Brian Lowe <muug-mail@groupbcl.ca> Sent: January 19, 2022 18:35 To: Continuation of Round Table discussion <roundtable@muug.ca> Subject: Re: [RndTbl] PHP undefined vars / array indices On Wednesday, January 19, 2022 9:08:52 A.M. CST John Lange wrote:
I submit that in the non-declarative case you can easily spend a ton of
time trying to trace the logic in the lower section of code without
realizing your mistake (been there, done that).
At the risk of adding fuel to a fire, I agree with this. I'm a Perl fan myself, and I always add "use strict;" to my code. I appreciate the compiler telling me that it hasn't seen "very_long_variab1e_name" before (did you notice I dropped the changed the "l" to a "1" in "variable"?)
Regarding Perl6, totally agree it should have been "Perl++".
Perl 6 does have a new name now; it was renamed to "Raku" in October 2019: https://www.raku.org.
But in IMHO
Perl dropped out of favour because of a point I made earlier, it is very
often unreadable and therefore hard to learn and maintain. This is made
worse by the fact that Perl programmers take pride in writing the most
unreadable code possible (there is even a contest for this) and then look
down their noses at less "expert" programmers who struggle to understand.
Very much this! There's a great temptation in Perl to play "code golf." I admit it feel cools to take a nicely nested if/then/else with a loop and turn it into:
@var = map { condition ? yes : no } sort grep { /regexp/ } @var;
It looks neat and is nice and concise, but maintainable? Not so much. These days I shy away from doing that even in code I write for my own use. Brian
On 2022-01-20 Hartmut W Sager wrote:
To clear my conscience, I finally have to weigh in with my vote on this topic, which has had a great discussion here!
I am an old-school ultra-hard-core algorithmic programmer (M.Sc. CompSci 1975) who absolutely believes in declaring everything, initializing everything before first use, etc. Inconvenience is heavily mitigated with a high-grade programmer's text editor (or a good IDE).
Love the hardcore! However, keep in mind that in '75 you didn't really get a choice regarding declaration. Most people get "imprinted" on their first (few) languages. I know I sure did. I went basic -> pascal -> perl -> C -> php/java/js/insert-modern-language-here. I still think a lot like a pascal programmer, but was able to shake the declarative/typed aspect. When I first saw perl I instantly fell in love and knew this is what I wanted a language to be like. I've never shaken the perl imprint, and carried that over to php, which was basically a better-for-web-perl at the time with virtually identical syntax and slightly renamed builtin functions. (Treasurer Brad, share with us your language path!!) I'm also firmly imprinted by procedural programming, as OO didn't really exist (well not as a "thing") when I was being imprinted. To this day I can't get myself to see the "big win" in a full-OO paradigm. And I've been forced to do many paid projects (and U assignments) in full-OO in the past. Even event-driven programming is easier for me to grasp and appreciate than full-OO. Some people are precisely the opposite.
I am appalled on a daily basis by the crap programming of Websites I encounter, even at places like Rogers, Fido, Telus/Koodo, Bell, etc., where I would expect to see much better (yeah, I visit those sites on behalf of others who can't even manage their own accounts). The one major exception is the big banks - for the most part, their Websites are functionally still a cut above the rest.
Ya, but I'd proffer that the above is more a function of bad programmers than bad languages. Many/most "big guys" sites are probably Java (typed / declarative / OO), not PHP/perl (loose). I have to deal with bad-programmer output on a semi-regular basis. It's bad no matter the language. I've seen some superb loose-language code in addition to garbage strict-language code.
The flurry of new "easy" languages we see seems to mainly exist to get people into "programming" who should never be programming anything serious in the first place. That's what produced Cobol ages ago, that's what produced Python, and the trend continues unabated.
That could possibly be true, especially if we think in terms of hobbyist / no-pro programmers. There's lots of admins who can't really program who pick up some bash/perl/python out of necessity. There's lots of web UI designers who pick up some PHP/ASP/js out of necessity. But they aren't really "programmers". I don't know what college/U use as the "1st/2nd year language" these days, but my guess is it might still be something typed, and probably heavily OO. I'm not sure they push "easy" languages except at a rudimentary level (i.e. "Programming for Arts students 101"). I could be wrong. There's always an aspect of elitism, in addition to psuedo-religion, when it comes to programmers and their languages. I can exhibit both myself (some MUUGers are spitting out their beverage right about now). We all think our favorite language and style is "the best". Nothing wrong with that, really. Made for some great flamewars over the (fidonet/usenet) years. ;-) The beauty of the current situation is there are so many languages to choose from, everyone can find their favorite. The freedom we have these days (in byte-land that is) is astonishing. But your comment ties back into the bad-programmer point. I agree that the level of competence (as Adam has pointed out) can be strikingly low. And that can make all of our daily lives a little more frustrating. I chalk this up a bit to the "10X Programmer" article I put in a MUUG newsletter a while back (there's my elitism!), there just aren't enough 10X ones to go around to every company! Not to mention companies often think hiring 10 bad programmers is better than hiring one expensive 10Xer. As a final note, I still maintain that the best programmers are born, not made. It's a talent, even a calling, and you either have it or you don't. Hire the ones that consider it a calling and the world will be a better place.
(Grossly simplified, and more or less just my opinion:) Problem is, the "born programmers" are the same people who would (largely) succeed in law, in engineering, in InfoSec, even in medicine. It's "simply" the ability to keep significant amounts of state in your head while intuitively understanding dependencies... and a healthy, and simultaneously ineffable, sense of curiosity. The ones who go the programmer route are mostly, I think(?), the ones who develop social skills sightly later, such that they're enamoured of computers early on. Others become top-notch machinists or similar careers that involve a lot of inanimate objects like, oh, geology or even physics/chemistry, sometimes woodworking or carpentry - top performers in almost every field share common traits. My point is that there aren't that many 10X programmers out there. So most companies have to make do without. I think the biggest disservice our industry has done to the world at large is enabling wannabe-programmers to do whatever they want... because clearly, a damn good chunk of them can't be trusted with that kind of power. (Just go read The Daily WTF for examples. Or any enterprise code-base, no matter what language.) YMMV. -Adam ________________________________ From: Roundtable <roundtable-bounces@muug.ca> on behalf of Trevor Cordes <trevor@tecnopolis.ca> Sent: Saturday, January 22, 2022 3:18:59 AM To: Hartmut W Sager <hwsager@marityme.net> Cc: Continuation of Round Table discussion <roundtable@muug.ca> Subject: Re: [RndTbl] PHP undefined vars / array indices On 2022-01-20 Hartmut W Sager wrote:
To clear my conscience, I finally have to weigh in with my vote on this topic, which has had a great discussion here!
I am an old-school ultra-hard-core algorithmic programmer (M.Sc. CompSci 1975) who absolutely believes in declaring everything, initializing everything before first use, etc. Inconvenience is heavily mitigated with a high-grade programmer's text editor (or a good IDE).
Love the hardcore! However, keep in mind that in '75 you didn't really get a choice regarding declaration. Most people get "imprinted" on their first (few) languages. I know I sure did. I went basic -> pascal -> perl -> C -> php/java/js/insert-modern-language-here. I still think a lot like a pascal programmer, but was able to shake the declarative/typed aspect. When I first saw perl I instantly fell in love and knew this is what I wanted a language to be like. I've never shaken the perl imprint, and carried that over to php, which was basically a better-for-web-perl at the time with virtually identical syntax and slightly renamed builtin functions. (Treasurer Brad, share with us your language path!!) I'm also firmly imprinted by procedural programming, as OO didn't really exist (well not as a "thing") when I was being imprinted. To this day I can't get myself to see the "big win" in a full-OO paradigm. And I've been forced to do many paid projects (and U assignments) in full-OO in the past. Even event-driven programming is easier for me to grasp and appreciate than full-OO. Some people are precisely the opposite.
I am appalled on a daily basis by the crap programming of Websites I encounter, even at places like Rogers, Fido, Telus/Koodo, Bell, etc., where I would expect to see much better (yeah, I visit those sites on behalf of others who can't even manage their own accounts). The one major exception is the big banks - for the most part, their Websites are functionally still a cut above the rest.
Ya, but I'd proffer that the above is more a function of bad programmers than bad languages. Many/most "big guys" sites are probably Java (typed / declarative / OO), not PHP/perl (loose). I have to deal with bad-programmer output on a semi-regular basis. It's bad no matter the language. I've seen some superb loose-language code in addition to garbage strict-language code.
The flurry of new "easy" languages we see seems to mainly exist to get people into "programming" who should never be programming anything serious in the first place. That's what produced Cobol ages ago, that's what produced Python, and the trend continues unabated.
That could possibly be true, especially if we think in terms of hobbyist / no-pro programmers. There's lots of admins who can't really program who pick up some bash/perl/python out of necessity. There's lots of web UI designers who pick up some PHP/ASP/js out of necessity. But they aren't really "programmers". I don't know what college/U use as the "1st/2nd year language" these days, but my guess is it might still be something typed, and probably heavily OO. I'm not sure they push "easy" languages except at a rudimentary level (i.e. "Programming for Arts students 101"). I could be wrong. There's always an aspect of elitism, in addition to psuedo-religion, when it comes to programmers and their languages. I can exhibit both myself (some MUUGers are spitting out their beverage right about now). We all think our favorite language and style is "the best". Nothing wrong with that, really. Made for some great flamewars over the (fidonet/usenet) years. ;-) The beauty of the current situation is there are so many languages to choose from, everyone can find their favorite. The freedom we have these days (in byte-land that is) is astonishing. But your comment ties back into the bad-programmer point. I agree that the level of competence (as Adam has pointed out) can be strikingly low. And that can make all of our daily lives a little more frustrating. I chalk this up a bit to the "10X Programmer" article I put in a MUUG newsletter a while back (there's my elitism!), there just aren't enough 10X ones to go around to every company! Not to mention companies often think hiring 10 bad programmers is better than hiring one expensive 10Xer. As a final note, I still maintain that the best programmers are born, not made. It's a talent, even a calling, and you either have it or you don't. Hire the ones that consider it a calling and the world will be a better place. _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2022-01-19 Brian Lowe wrote:
At the risk of adding fuel to a fire, I agree with this. I'm a Perl fan myself, and I always add "use strict;" to my code. I appreciate the compiler telling me that it hasn't seen "very_long_variab1e_name" before (did you notice I dropped the changed the "l" to a "1" in "variable"?)
That's the beauty of perl. You use strict, I don't, Brad does, some other guy doesn't. Even better, you can use strict on a new project, but disable it on an old project you don't want to change 20k lines for! (I did try when strict came out, I really did! Just couldn't take it!) :-)
Regarding Perl6, totally agree it should have been "Perl++".
Perl 6 does have a new name now; it was renamed to "Raku" in October 2019: https:// www.raku.org.
Darn, I knew that somewhere in my brain! I think I even wrote a newsletter article about it years ago. Doh. Goes to show what kind of name recognition Raku gets :-) To me it will always be known as perl 6!
@var = map { condition ? yes : no } sort grep { /regexp/ } @var;
It looks neat and is nice and concise, but maintainable? Not so much. These days I shy away from doing that even in code I write for my own use.
Love it! Map came out way late in my perl game so I'm still working it into my brain-flow, but it allows for some amazing condensing of foreach blocks. It's actually easy to read if you know the secret: start on the right. Easier if you put a this above the line: # pull out so-n-so entries, sort and change them in such-n-such a way Don't see any problem with that! How do you win putting that comment above 20 lines of foreach block vs putting it above your crazy one map line? The surprising thing to most people is the amount of development and innovation perl5 experiences every year to this very day. And the new, crazy language-changing extras the CPAN people come up with is shocking. Check out the perl*delta man pages: man perldelta / man 5321delta or find /usr/share/man/ | grep perl | grep delta | sort You could waste a day playing with all the new features over the years (and the often funny comments in said manpages). Need a separate perl thread now! :-)
On 2022-01-19 John Lange wrote:
I submit that in the non-declarative case you can easily spend a ton of time trying to trace the logic in the lower section of code without realizing your mistake (been there, done that).
Of course, I do it on occasion too. And then I debug for 15 minutes and smack my head when I see the error. Such is the life of a programmer. But it (still) has not been proven to be a security hole or massive performance boost or great new programmer timesaver (like hashes/dictionaries were when introduced), which are usually the impetuses (real word!) for big backwards-incompatible changes. I'm all for features that ease the burden on the programmer, and agree with everything you said, but not at the expense of freedom. Especially so when you can easily argue it boils down to a style choice.
Regarding Perl6, totally agree it should have been "Perl++". But in IMHO Perl dropped out of favour because of a point I made earlier, it is very often unreadable and therefore hard to learn and maintain. This is made worse by the fact that Perl programmers take pride in writing the most unreadable code possible (there is even a contest for this) and then look down their noses at less "expert" programmers who struggle to understand. This is very ironic given the whole reason interpreted languages were developed in the first place was to make them more "human readable".
Congratulations Perl developers! You played yourself!
Yes, there are many reasons perl lost the best-glue trophy, and that's a discussion in and of itself (which I ponder regularly). However, unless you're doing one-liners, most perl coders don't try to make unmaintainable code. We all know almost everything we write we'll go back and tinker with in the future. No sense shooting yourself in the foot. Perl is kind of the ultimate freedom in that you can code in so many different ways. You can make it look almost like bash if you're a bash guy. Or almost like C if you're a C guy. Or almost like a real OO (but better!) language (look up MOOSE!). Or you can learn The Perl Way and code to that style. Heck, you can go 2nd order and code in ways that would amaze most (read Higher Order Perl). Of course, some people would say this is the worst part of perl. All depends on perspective. The neat thing about perl is you can learn a bit from all of those styles and incorporate what you like into your style, to suit your comfort level.
On 2022-01-19 4:49 a.m., Trevor Cordes wrote:
On 2022-01-13 Adam Thompson wrote:
I don’t really have a horse in this race, but I think John make one factual error. It’s minor and doesn’t change his point, but: if(!i++) { ... } is perfectly valid in C, where 0==false. It’s equivalent to (I think…): if(i==0) { i++; ... } else { i++; ... }; IIRC, C has the comma operator, albeit thankfully rarely used, so if you really wanted to do this, I think it could be slightly better written: if(i==0, i++) { ... } I could be wrong, I haven’t attempted to write C code in 25+ years. It’s not something you would want to see, but you certainly could.
Hey, I use comma all the time! :-) Well, when it makes sense. Usually in super long perl-oneliners or to get a lot accomplished in one expression in a perl regex using /e.
Perl allows your if(i==0,i++) so I'm nearly positive C would too (Brad, paging Brad...).
I'm quite sure C/C++ would allow the comma operator in conditional contexts (if/while), but keep in mind that the resulting value is the expression to the right of the comma, i.e. i++ in the above example (the i==0 would have no net effect). ...
The more I seethe about the PHP change, the more I seriously ponder making my own fork, or my own "unfixed"-version repo, or trying to get a granular logging feature introduced into master project (h/t Richard). The real tell would be if I made a great granular log settings patch (like Node, again h/t Richard) and PHP rejected it because their real goal is to force their style choices on the world (I'd peg that at 50/50 at the moment... or worse).
I'd hold off on making/maintaining your own fork until such a time the PHP brain-trust actually raises things from a warning to an error. In the meantime, if you're logging using rsyslog, it would be fairly easy to add a one-line filter rule to eliminate the needlessly-noisy warning messages. No more full logs, and no more actual serious warnings getting lost like a needle in the haystack! -- Gilbert E. Detillieux E-mail: <gedetil@cs.umanitoba.ca> Dept. of Computer Science Web: http://cs.umanitoba.ca/~gedetil/ University of Manitoba Winnipeg MB CANADA R3T 2N2
On 2022-01-19 Gilbert E. Detillieux wrote:
I'd hold off on making/maintaining your own fork until such a time the PHP brain-trust actually raises things from a warning to an error. In the meantime, if you're logging using rsyslog, it would be fairly easy to add a one-line filter rule to eliminate the needlessly-noisy warning messages. No more full logs, and no more actual serious warnings getting lost like a needle in the haystack!
There's an inherent problem in the FLOSS / dev process, especially regarding PHP, and that is they are deciding things 2-3 years before they materialize in most distros; maybe even longer for enterprise production stacks. That means very few potential stakeholders (including everyday PHP programmers) will realize/notice disastrous decisions until it is far too late to take part in the discussion. It really leaves the 60-ish PHP dev/voters free rein with no timely pushback. While I'm moaning about a warning, they are raring to go full-error, I'm sure. It's actually quite shocking that this poor-path-choices scenario crops up so rarely! I guess it's a testament to the good governance / benevolent dictatorship of most projects most of the time. We're kind of lucky in this case because I noticed these things a while back reading PHP 8.x changelogs, and have been writing about the craziness in the newsletter for a couple of years. (However, I didn't believe some of the more insane plans.) How many would know about this if not for MUUG (assuming it's someone who remotely cares)? Although, not like being aware has helped at all. Like Adam said, it's like systemd, it shows up and is shoved down your throat, leaving many people with a bad taste. As for your log-filtering idea: it may be the easiest way out for now. However, PHP by default currently logs straight to file. I'm sure there's a syslog option I'll have to explore. I guess it'll add some overhead, but it shouldn't be too much. I didn't know (r)syslog had a filtering option beyond the level-filtering! So does it allow string search or regex or something? Have you used this in the past? A quick example? Thanks for the input! P.S. Maybe I'll take the filtered out UV/UAI warnings in syslog and do | mail -s 'thanks for nothing' 36phpdevsvotingyes@php.net Hahaha, just kidding!
On Sat, 2022-01-22 at 01:58 -0600, Trevor Cordes wrote:
On 2022-01-19 Gilbert E. Detillieux wrote:
I'd hold off on making/maintaining your own fork until such a time the PHP brain-trust actually raises things from a warning to an error. In the meantime, if you're logging using rsyslog, it would be fairly easy to add a one-line filter rule to eliminate the needlessly-noisy warning messages. No more full logs, and no more actual serious warnings getting lost like a needle in the haystack!
We're kind of lucky in this case because I noticed these things a while back reading PHP 8.x changelogs, and have been writing about the craziness in the newsletter for a couple of years. (However, I didn't believe some of the more insane plans.) How many would know about this if not for MUUG (assuming it's someone who remotely cares)? Although, not like being aware has helped at all. Like Adam said, it's like systemd, it shows up and is shoved down your throat, leaving many people with a bad taste.
For what it's worth this change has been a very long time in coming, and the stewards of PHP couldn't even agree to rip off the band-aid when the proposal was made for PHP 8.0. E_ALL has been the "recommended" and later "development" (non-default) error reporting level going all the way back to PHP 4.1 in December of 2001. Later E_ALL & ~E_DEPRECATED (with ~E_STRICT added while it existed) was made the "production" (default) error reporting level in PHP 5.3 in June of 2009. In other words, unless you haven't touched your PHP configuration in over a decade, you should already have been aware silencing notices is not the norm. If you've published a library to PEAR or Packagist in the last thirteen years, you've either already made the change, or have been inconveniencing people using default PHP configurations for a very long time. Far from being "insane", the current state of affairs is a very gentle and gradual move away from something which (whether you agree or not) has been considered bad practice by those guiding the evolution of the language for over twenty years Personally, I'd have preferred if the E_NOTICE category had been retired rather than E_STRICT <https://wiki.php.net/rfc/reclassify_e_strict>, with then-current language-use E_NOTICE events converted to E_STRICT. How a notice materially differs from a warning is pretty nebulous, but a "STRICT" category is at least obvious in meaning, if not necessarily in severity. -- J. King <jking@jkingweb.ca>
On 2022-01-22 1:58 a.m., Trevor Cordes wrote:
On 2022-01-19 Gilbert E. Detillieux wrote:
I'd hold off on making/maintaining your own fork until such a time the PHP brain-trust actually raises things from a warning to an error. In the meantime, if you're logging using rsyslog, it would be fairly easy to add a one-line filter rule to eliminate the needlessly-noisy warning messages. No more full logs, and no more actual serious warnings getting lost like a needle in the haystack! ... As for your log-filtering idea: it may be the easiest way out for now. However, PHP by default currently logs straight to file. I'm sure there's a syslog option I'll have to explore. I guess it'll add some overhead, but it shouldn't be too much. I didn't know (r)syslog had a filtering option beyond the level-filtering! So does it allow string search or regex or something? Have you used this in the past? A quick example?
It's been a while since I looked into rsyslog filtering (which isn't found in the original syslogd), so I'd recommend you RTFM... But here's an example I did set up some time ago to suppress messages from an overly-chatty Avahi daemon... /etc/rsyslog.d/avahi.conf: # Not interested in this noise from avahi... if $programname == 'avahi-daemon' and $msg contains 'Invalid response packet from host' then ~ if $programname == 'avahi-daemon' and $msg contains 'with invalid source port' then ~ if $programname == 'avahi-daemon' and $msg contains 'Packet too short or invalid' then ~ if $programname == 'avahi-daemon' and $msg contains 'Invalid legacy unicast query packet' then ~
Thanks for the input!
You're welcome! Gilbert -- Gilbert E. Detillieux E-mail: <gedetil@cs.umanitoba.ca> Dept. of Computer Science Web: http://cs.umanitoba.ca/~gedetil/ University of Manitoba Winnipeg MB CANADA R3T 2N2 For best service, contact <cstech@cs.umanitoba.ca>.
And further to the RTFM recommendation... https://www.php.net/manual/en/errorfunc.configuration.php#ini.error-log rsyslog.conf(5) FILTER CONDITIONS section https://www.thegeekdiary.com/etc-rsyslog-conf-setup-a-filter-to-discard-or-r... https://kifarunix.com/a-basic-introduction-to-rsyslog-filters/2/ https://www.usenix.org/system/files/login/articles/06_lang-online.pdf Gilbert On 2022-01-24 10:30 a.m., Gilbert E. Detillieux wrote:
On 2022-01-22 1:58 a.m., Trevor Cordes wrote:
On 2022-01-19 Gilbert E. Detillieux wrote:
I'd hold off on making/maintaining your own fork until such a time the PHP brain-trust actually raises things from a warning to an error. In the meantime, if you're logging using rsyslog, it would be fairly easy to add a one-line filter rule to eliminate the needlessly-noisy warning messages. No more full logs, and no more actual serious warnings getting lost like a needle in the haystack! ... As for your log-filtering idea: it may be the easiest way out for now. However, PHP by default currently logs straight to file. I'm sure there's a syslog option I'll have to explore. I guess it'll add some overhead, but it shouldn't be too much. I didn't know (r)syslog had a filtering option beyond the level-filtering! So does it allow string search or regex or something? Have you used this in the past? A quick example?
It's been a while since I looked into rsyslog filtering (which isn't found in the original syslogd), so I'd recommend you RTFM... But here's an example I did set up some time ago to suppress messages from an overly-chatty Avahi daemon...
/etc/rsyslog.d/avahi.conf:
# Not interested in this noise from avahi... if $programname == 'avahi-daemon' and $msg contains 'Invalid response packet from host' then ~ if $programname == 'avahi-daemon' and $msg contains 'with invalid source port' then ~ if $programname == 'avahi-daemon' and $msg contains 'Packet too short or invalid' then ~ if $programname == 'avahi-daemon' and $msg contains 'Invalid legacy unicast query packet' then ~
Thanks for the input!
You're welcome!
Gilbert
-- Gilbert E. Detillieux E-mail: <gedetil@cs.umanitoba.ca> Dept. of Computer Science Web: http://cs.umanitoba.ca/~gedetil/ University of Manitoba Winnipeg MB CANADA R3T 2N2 For best service, contact <cstech@cs.umanitoba.ca>.
On 2022-01-13 John Lange wrote:
As a former professional PHP programmer and current hobbyist programmer (not in PHP though), I agree with Trevor. (disclaimer: I did not go back and re-read all the PHP threads on this topic).
Thanks John! I also agree with everything you said. (Sorry for the delayed response!)
function Foo { while ( $i < 5 ) if (!$i++) {} // ... (a whole bunch more lines of code go here) ..
while ( $i < 5 ) // inadvertently using the same variable because $i is your favorite 'counter' and you forgot you already used it if (!$i++) { } // This line never runs }
Good example, but the funny part is, even this bug would not be addressed by the new PHP initialization rules! The PHP change requires only this: function Foo { $i=0; # <<<<<<<<<<<<<<<<<--------------------- while ( $i < 5 ) if (!$i++) {} // ... (a whole bunch more lines of code go here) .. while ( $i < 5 ) // inadvertently using the same variable because $i if (!$i++) { } // This line never runs } Which doesn't help this bug at all. Of course, no language can ever tell you you probably meant to add a second $i=0, thus proving my point that you can only hand-hold so much. The programmer has to be expected to be at a certain level of competency. My other main point I made earlier, as it applies to your example is I can't envision a way that such a bug could be a security hole: not without coming up with a ridiculously contrived example. That's why when the VOTE YES side says "robustness" & "safety", I'm dubious.
But never the less the point is I agree that PHP should not have broken backward compatibility. By doing so it will force many sites to remain on PHP 7.x thereby opening up the very real possibility that a 7.x security vulnerability will get exploited and cause mass-grief (log4j anyone?).
That's a great point. I've already talked with some people who said their solution would probably be stick with 7 as long as possible, even past EOL date.
participants (7)
-
Adam Thompson -
Brian Lowe -
Gilbert E. Detillieux -
Hartmut W Sager -
J. King -
John Lange -
Trevor Cordes