January 29th, 2021 at 4:12 AM
I have spent nearly an hour looking through various online threads on these two subjects. Goto and Eval. They are both widely considered inherently evil (and to be avoided at all costs). And it's largely for good reason. The viewpoint of the majority is not always correct, but in this case, it's a slam dunk. There are very few use cases where the presence of these constructs is truly justified (and with GOTO especially, as there are even fewer valid uses for GOTO than for EVAL).
Why?
Starting with EVAL, it's highly problematic for serious reasons. Eval allows arbitrary code to be executed from a variable. This opens the door for all kinds of PHP code injection vulnerabilities or other hard-to-trace problems. In fact, EVAL is most often encountered in the wild when it is accompanied by a malicious backdoor. Its presence is rarely a good thing.
And yet there are (rare) uses where it makes sense to use it. Perhaps the best truly valid use is for evaluating mathematical expressions (where writing a tokenizer/parser yourself would be tedious). Certain template engines (including my own) also use eval as a fallback in the rare case that compiled/cached templates cannot be written to the filesystem. In such cases as this, it makes sense to use eval. There is simply no other way to render compiled templates from memory in the event that the filesystem fails.
However, (scary as it may seem), there are applications that actually rely on it. MyBB is a perfect example. Eval is used on almost every single page to render every single template in the forum software. Believe me, it's a security risk. They do a lot of very rigorous filtering of the templates before passing it to the parser to stop any malicious activity, which largely mitigates the problem. But without their rigorous filters, this would open the door wide for all sorts of issues. And even still, we're relying on the robustness of their security hardnening, and there is simply no guarantee that there aren't dormant vulnerabilities.
Goto on the other hand, is a little more of an enigma. It's the statement that's both ridiculously powerful and ridiculously messy. There is very little (nothing really) that it can do in ways that functions can't. And while in certain rare edge cases, goto might shave a line or two, it also confuses those reading it. Goto is one of those statements that is so rarely used that most people forget it even exists.
The question has to be asked: Why are you using GOTO? Almost always, functions can solve this problem better, with less confusing syntax.
Relying on GOTO would be like building a house with PCP pipes as the backbone of its structure. Sure, it could be done. But it'd be a bit of a black magic science that would totally shatter every notion of what it means to be in the construction industry. To actually rely on such a silly substance for the bedrock of a building would be laughable. Such is the perception of using GOTO to handle program flow. It simply just isn't done on a large scale by any reputable programmer. Ever.
Either way, these two constructs still find themselves in the wild (from time to time). Have you ever encountered them? Have you ever seen a good, valid use for either of these?
Why?
Starting with EVAL, it's highly problematic for serious reasons. Eval allows arbitrary code to be executed from a variable. This opens the door for all kinds of PHP code injection vulnerabilities or other hard-to-trace problems. In fact, EVAL is most often encountered in the wild when it is accompanied by a malicious backdoor. Its presence is rarely a good thing.
And yet there are (rare) uses where it makes sense to use it. Perhaps the best truly valid use is for evaluating mathematical expressions (where writing a tokenizer/parser yourself would be tedious). Certain template engines (including my own) also use eval as a fallback in the rare case that compiled/cached templates cannot be written to the filesystem. In such cases as this, it makes sense to use eval. There is simply no other way to render compiled templates from memory in the event that the filesystem fails.
However, (scary as it may seem), there are applications that actually rely on it. MyBB is a perfect example. Eval is used on almost every single page to render every single template in the forum software. Believe me, it's a security risk. They do a lot of very rigorous filtering of the templates before passing it to the parser to stop any malicious activity, which largely mitigates the problem. But without their rigorous filters, this would open the door wide for all sorts of issues. And even still, we're relying on the robustness of their security hardnening, and there is simply no guarantee that there aren't dormant vulnerabilities.
Goto on the other hand, is a little more of an enigma. It's the statement that's both ridiculously powerful and ridiculously messy. There is very little (nothing really) that it can do in ways that functions can't. And while in certain rare edge cases, goto might shave a line or two, it also confuses those reading it. Goto is one of those statements that is so rarely used that most people forget it even exists.
The question has to be asked: Why are you using GOTO? Almost always, functions can solve this problem better, with less confusing syntax.
Relying on GOTO would be like building a house with PCP pipes as the backbone of its structure. Sure, it could be done. But it'd be a bit of a black magic science that would totally shatter every notion of what it means to be in the construction industry. To actually rely on such a silly substance for the bedrock of a building would be laughable. Such is the perception of using GOTO to handle program flow. It simply just isn't done on a large scale by any reputable programmer. Ever.
Either way, these two constructs still find themselves in the wild (from time to time). Have you ever encountered them? Have you ever seen a good, valid use for either of these?
![[Image: autism4all.png]](https://www.autism4all.at/datein/autism4all.png)
![[Image: 5.jpg]](http://www.nodiatis.com/pub/5.jpg)
