I have logical expressions that I need to evaluate. After some expresison template parametrized with its parameters, these expressions could look like this:
$expr1 = '1 or 0 and not(0 or 0)';
$expr2 = "'editor' == 'editor' and not(0 = 1) and 10 > 5";
So, I need to handle numbers, string literals, as well as logical and algebraical operators and round brackets between them.
When using PHP eval I also get undesirable unsecured abilities, like system function call, and so on.
So, is there any way to restrict PHP eval, or may be there is some better solution?
Thanks!
You could use a tokenizer to check that the expressions don't contain function calls.
See the safer eval() class for an example.
Ok, I got another solution. I've dawned that I can use PHP DOMXPath::evaluate to evaluate my logical expression. So, I got a working solution, which has no security issues. I think my problem is solved :)
Related
For example
$var = '10/2';
Is there a way for me to output the value 5 from that easily?
So something like this:
$foo = ($var) + 5;
I want $foo to have a value of 10?
Currently, the best way I know is to explode $var and then divide $var[0] by $var[1]. Is there a quicker way?
Another way of asking; Is there a way to tell the system to treat '10/2' as an equation instead of a string?
Could be you can use a solution like this
$foo = eval('return '.$var +5 .';');
print $foo;
eval require a line of code .. so you could build a valid code line
eval() to either assign in place or return:
eval("\$foo = ($var) + 5;");
$foo = eval("return ($var) + 5;");
First things first, EVAL IS HAZARDOUS AND SHOULD NEVER BE USED UNLESS YOU KNOW WHAT YOU'RE DOING! As an addendum to this, you don't know what you're doing. No matter how experienced you are as a programmer, when it comes to eval just assume you don't know what you're doing. Believe me, in the long run your sanity will thank you.
As for your problem, you're basically asking how to write an equation parser. Writing a full blown one that can handle all cases of valid input (and reliably identify invalid input) is a much bigger job than you might at first think, so if you really do need to parse string equations it may be better to look for a library that will do it for you because the chances are whoever wrote the library thought of a lot of stuff that you didn't, such as handling operator precedence and how parenthesis can modify it, how to pass strings in scientific notation, etc.
One of your comments suggests using PHP Math Parser. I've never personally used it, but I know the author by reputation well enough to believe it's a reliable library.
If your use case is always going to be as simple as your example then you can simply split the string and process the resulting fragments.
$parts = explode ("/", $var);
$foo = $parts[0] / $parts[1];
I don't know if it's just me or not, but I am allergic to one line ifs in any c like language, I always like to see curly brackets after an if, so instead of
if($a==1)
$b = 2;
or
if($a==1) $b = 2;
I'd like to see
if($a==1){
$b = 2;
}
I guess I can support my preference by arguing that the first one is more prone to errors, and it has less readability.
My problem right now is that I'm working on a code that is packed with these one line ifs, I was wondering if there is some sort of utility that will help me correct these ifs, some sort of php code beautifier that would do this.
I was also thinking of developing some sort of regex that could be used with linux's sed command, to accomplish this, but I'm not sure if that's even possible given that the regex should match one line ifs, and wrap them with curley brackets, so the logic would be to find an if and the conditional statement, and then look for { following the condition, if not found then wrap the next line, or the next set of characters before a line break and then wrap it with { and }
What do you think?
Your best bet is probably to use the built-in PHP tokenizer, and to parse the resulting token stream.
See this answer for more information about the PHP Tokenizer: https://stackoverflow.com/a/5642653/1005039
You can also take a look at a script I wrote to parse PHP source files to fix another common problem in legacy code, namely to fix unquoted array indexes:
https://github.com/GustavBertram/php-array-index-fixer/blob/master/aif.php
The script uses a state machine instead of a generalized parser, but in your case it might be good enough.
$specify_step = ($_GET['specify_step']) ? $_GET['specify_step'] : getNextStep($returnId,$type);
Given the above statement, is there a way to shorthand this if statement even more so that I don't have to say $_GET['specify_step'] twice?
In the cases when I'm accessing GET or COOKIES etc, it always seems redundant and "wordier" then it needs to be.
I don't think it gets much more compact than that. My only thought is to make a temporary variable to hold $_GET['specify_step'], but that doesn't seem any shorter.
$specify_step = ($_GET['specify_step']) ?: getNextStep($returnId,$type);
It made enough logical sense to me that I had to go look it up....and according to php.net, it works in PHP 5.3. If you're using 5.3, you're in luck.
As I mentioned in a comment to your question, I don't know PHP.
Check if this works. In most langauages, if the first part is true, the function getNextStep won't be called.
$specify_step = ($_GET['specify_step']) || getNextStep($returnId,$type);
There would be this alternate boolean evaluation approach, but it just goes to show that you have to duplicate something:
$specify_step = $_GET['specify_step']
or
$specify_step = getNextStep($returnId,$type);
(Also works without decorative linebreaks.)
With PHP 5.3 you might of course use the ?: shortcut. If that's available.
Personally I can alternate to $_GET->default('specify_step', 123) for such cases.
In this code fragment:
$results = $this->getAdapter()->fetchAll($query);
if(count($results)) {
// …
}
…do you consider the if(count()) part to be be a well understood idiom, or confusing code. i.e. should it be
if(count($results) > 0)
???
Using a boolean expression with 'if' requires less understanding of a language than using implicit conversions, so I would always prefer the second option (adding "> 0") - at least if this code is meant to be read by others, too. You never know who will maintain your code. The keyword is "clarity" here.
But I must admit I have written many times code with if's using an int expression myself, too, because I like its elegance.
They are doing exactly the same job in this context, and are both easily readable.
I'll just add (just in case) that if you're performing this query only to if(count()), then you should be issuing a SELECT COUNT(*) instead!
The count and the extraneous > comparison are pointless. If you receive an actualy array, then the test should just be:
if ($results) {
That's what scripting languages are for. Abstracting low level details away.
You would only need the count if your fetchAll function returns an ArrayObject or similar. Should your function sometimes return a false for example, then your if (count( is going to fail (because count(false)==1 in PHP).
erm...not realy sure what the purpose of this question is - but the semantics should be self-evident to anyone whom understands PHP
My opinion is that the > 0 check is redundant and unnecessary.
I know other developers who insist that it should be there for clarity, but frankly I can't why -- anyone who can read PHP should be able to discern that they are identical.
I was wondering if there is any nice way of writing functions in PHP so that they don't require ( ) around the parameters.
Example:
function sayThis($str) {
echo $str;
}
sayThis "hi!!";
Thanks,
Matt Mueller
There simply isn't. "echo" is more of an operator than a function, so you'd actually need to rewrite the PHP interpreter source in order to introduce new "functions" like those.
Edit: Actually, the more accurate term for "echo" is, as eyze has correctly pointed out, language construct rather than operator. http://php.net/manual/de/function.echo.php provides some more information.
Simple answer, no.
echo is a language construct not a function, hence it doesn't need the parentheses.