Warning: Division by zero in ..\session.php on line 2
After updating my PHP to the most current version my host allows (5.5.9) there was a small issue with the session path so I had to include a small snip-it of code before the session_start() to fix it. However this odd error is happening, apparently it thinks I am attempting to divide by zero? I would like to know how to fix that if it is possible, I assume it is just PHP being stupid however.
Thanks! :)
Below is the first few lines of code
<?php
session_save_path(“/tmp”);
session_start();
//error_reporting(0);
EDIT: Fixed the issue using the code below
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
ini_set('session.gc_probability', 1);
It's the difference in the quotes used. PHP thinks you're trying to divide a string by another string. Change that to regular double-quotes and the problem will be resolved.
Right now, this is what PHP sees:
“/tmp”
^--- first string
^--- division operator
^^^^--- second string
The string is cast to an int before the operation, and that effectively turns both sides to 0, hence causing the Division by zero warning. You'd have caught this if you had enabled error reporting.
You have smart quotes.
Your code is therefore being interpreted as:
Unquoted string literal “
Divide by...
Unquoted string literal tmp“
Division casts to numbers, both sides get cast to zero, result is 0/0.
Related
I did a find-replace and made a mistake which led to the following code being on it's own line.
16;
This caused a lot of issues as it did not produce any errors anywhere and I am very surprised. How is this possibly valid PHP code?
16 is a valid literal. In itself it is a valid expression. 16; is a statement made up of the expression 16 which consists of the single value 16. There's nothing invalid. It simply doesn't do anything.
In this code golf answer, aross gives a solution that presumably uses IBM-850 encoding as parameter values in PHP"
echo preg_filter("/^(.*?[aeiouy]+)/i","$1 $1 $0",$argn);
echo preg_filter(~ðíÎÐı└ñ×ÜûÉèåóÈÍðû,~█╬▀█╬▀█¤,$argn); # Encoded
How does this work? Why are the parameters not quoted? How come only the parameters are encoded and not the rest of the code?
It hasn't so much to do with IBM-850, that's just a codepage filling out the 8th bit beyond ASCII to give a representation to the bytes you'll end up with.
The key here is the bitwise not operator ~ which flips all the bits - 0 becomes 1, and 1 becomes 0. If you dump ~"/^(.*?[aeiouy]+)/i" to a file and open it up as 850 it'll look like:
ðíÎÐı└ñ×ÜûÉèåóÈÍðû
And likewise ~"$1 $1 $0" looks like:
█╬▀█╬▀█¤
So you see where this is headed.
In PHP an undefined constant is assumed to have a string value matching its name. For example:
var_dump(foo);
Outputs string(3) "foo" (as well as the notice "Use of undefined constant foo - assumed 'foo'", if notices are on.)
When either of the two gibberish strings above are put in a PHP script without quotes they're taken as undefined constants with their names assumed for their values as well.
Now prepend each with ~ to flip their bits back and you've got the original regex and replacement strings:
preg_filter("/^(.*?[aeiouy]+)/i","$1 $1 $0",$argn)
Only those parameters had their bits flipped because they're the only string literals, which is what this trick applies to. For each string it's shaving off a pair of quotes in exchange for taking on only a single tilde.
The bit flipping had to be done because either of the original strings on their own without quotes would've landed parse errors.
Clever way to net two bytes.
I was doing some coding on my phone when I got this error:
Parse error: syntax error, unexpected '"log.txt"' (T_CONSTANT_ENCAPSED_STRING) in your code on line 15
This is the offending code:
$file = "log.txt";
Note that you have to copy this exactly to get this result. This is because when I retype it:
$file = "log.txt";
I get no error. The two lines are the same, except for one thing: the second space in the line is binary "10100000" in the crashing statement, but "00100000" in the retyped one.
So I suppose my editor screwed up in some mystical way I will probably never discover. But what I don't get is why does this bad character look exactly like a space (as opposed to something else or a �), and why does it cause this particular error as if I didn't properly open my string?
It's a non-breaking space character.
It probably came about as a result of copying the code in from a blog post or from Word, for example.
The interpreter is not able to parse it as a regular space, hence the error.
So I have a string that for some reason, is returning as: 12×12. I did this in my code: utf8_decode($variant['size']) and received 12×12.
But this still isn't matching my string of 12x12
So I have 12×12 that is not showing as equal in php with: 12x12.
The X does look a little different but how do I fix this issue?
In 12×12 the × is the multiplication symbol, which obviously doesn't equate to x. Note that × doesn't reach the baseline in the text.
You should test for this multiplication symbol instead, if you can.
Is there any difference between typing:
<?php echo $_SERVER[REQUEST_URI] ?>
or
<?php echo $_SERVER['REQUEST_URI'] ?>
or
<?php echo $_SERVER["REQUEST_URI"] ?>
?
They all work... I use the first one.
Maybe one is faster than the other?
Without quotes PHP interprets the REQUEST_URI as a constant but corrects your typo error if there is no such constant and interprets it as string.
When error_reporting includes E_NOTICE, you would probably get an error such as:
Notice: Use of undefined constant REQUEST_URI - assumed 'REQUEST_URI' in <file path> on line <line number>
But if there is a constant with this name, PHP will use the constant’s value instead. (See also Array do's and don'ts)
So always use quotes when you mean a string. Otherwise it can have unwanted side effects.
And for the difference of single and double quoted strings, see the PHP manual about strings.
The first one is wrong - you're actually looking for a constant REQUEST_URI that doesn't exist. This will generate a notice-level warning.
There's no difference between the other two.
There is a difference between single and double quotes in PHP string handling. A string enclosed in double quotes will be evaluated for embedded variables and escape characters (e.g. \n); a string enclosed in single quotes won't (or not as much).
So, for example,
$hello = "world";
echo "Hello $hello!\n";
echo 'Hello $hello!\n';
echo 'Done';
will output
Hello world!Hello $hello!\nDone
In situations where you have no escape characters or embedded variables, it is slightly more efficient to use single quotes as it requires less processing of the string by the runtime. However, many people (me included) prefer to use double quotes for all strings to save confusion.
As a caveat to Gumbo's answer the third representation - double quotes - actually makes PHP look for variables inside that string. Thus that method might be a little slower (although in a string of 11 characters it'll be negligible - it's better practice not to make PHP do that however).
When PHP comes across plain strings being used as array keys it checks if there is a constant with that name and if there isn't it defaults it back to an array key. Therefore, not using quote marks causes a slight performance hit and there is a possibility that the result will not be what you expect.
$_SERVER[REQUEST_URI]
is syntatically incorrect and AFAIK will not run on a default installation of PHP5. The array index is a string so it needs to be passed on strings. I know PHP4 converted undefined constants to strings inside the square brackets but it's still not good practice.
EDIT: Well unless you define a constant called REQUEST_URI, which you haven't in your example script.
$_SERVER['REQUEST_URI']
is the standard method and what you should be using.
$_SERVER["REQUEST_URI"]
also works and while not wrong is slightly more work for the PHP interpreter so unless you need to parse it for variables should not be used. (and if you need to do so, you need to rethink that part of your program.