Check if $_GET["menu"] is null.

[Nuno Paquete]

Hi group.
I'm using this code to see if is there any parameter for variable "menu":

if($_GET["menu"] == "downloads" )
....

But this code log errors if there is no parameter passed (this heappens at
the first time the page is loaded).

I tryed this code:

if($_GET["menu"] != ""){
if($_GET["menu"] == "downloads" )
...

But this log the same error on the second line.
Any help hould be greattly appreciated.
Thanks in advance,

Nuno Paquete

[Zurab Davitiani]

Chung Leong wrote:

Well, those are pretty lousy examples, as they're both wrong. An empty
string will get cast to 0 on a comparison with a number, so
if($_GET['x']== 0) will give you unexpected behavior even if do a isset()
first. The correct way to check if the user actually entered '0' is
if($_GET['x'] == '0'), which works as expected even if you do
if(@$_GET['x'] == '0').
I don't think it's *the* correct way. Call it "lousy examples" all you want.
What if you are comparing the $_GET['x'] to an integer variable that's set
to 0 and not to string '0'?
Personally I see nothing wrong with ignoring the invalid index notices. In
practice there's little difference between index.php and
index.php?get=[empty]. These variable don't come out of nowhere after
all. If you have one script that expects variable X, then you probably
have another script that either post to that script or link to it.

The only case I can think of where there's a difference between a unset
and empty variable is a search page that submits to itself, where the
former means the user enters the page initially, while the latter means
s/he didn't enter a search criteria.

I didn't give any practical examples. Yes, it's not likely to happen but
there is a remote chance that a notice during development may slip by. And
a remote chance after that it will have an unintended effect on your
script. So, I don't think it's "clean" way to do it.

[Ian.H]

On Sat, 31 Jul 2004 19:20:07 +0000, Zurab Davitiani wrote:

Well, those are pretty lousy examples, as they're both wrong. An empty
string will get cast to 0 on a comparison with a number, so
if($_GET['x']== 0) will give you unexpected behavior even if do a isset()
first. The correct way to check if the user actually entered '0' is
if($_GET['x'] == '0'), which works as expected even if you do
if(@$_GET['x'] == '0').

I don't think it's *the* correct way. Call it "lousy examples" all you want.
What if you are comparing the $_GET['x'] to an integer variable that's set
to 0 and not to string '0'?

if ($_GET['x'] === 0) {

Regards,

Ian

--
Ian.H
digiServ Network
London, UK
http://digiserv.net/

[Zurab Davitiani]

Ian.H wrote:

I don't think it's *the* correct way. Call it "lousy examples" all you
want. What if you are comparing the $_GET['x'] to an integer variable
that's set to 0 and not to string '0'?

if ($_GET['x'] === 0) {

And that will evaluate to false because $_GET['x'] will be a string. I
alluded to that option in my previous post in this thread and pointed out
you would lose the implicit type convertion capability in PHP; at least in
PHP4 - I believe there were some type convertion changes in PHP5 that I
haven't completely tried out yet, but that's a different issue.

[Ian.H]

On Sun, 01 Aug 2004 01:28:39 +0000, Zurab Davitiani wrote:

Ian.H wrote:

I don't think it's *the* correct way. Call it "lousy examples" all you
want. What if you are comparing the $_GET['x'] to an integer variable
that's set to 0 and not to string '0'?

if ($_GET['x'] === 0) {

And that will evaluate to false because $_GET['x'] will be a string. I
alluded to that option in my previous post in this thread and pointed out
you would lose the implicit type convertion capability in PHP; at least in
PHP4 - I believe there were some type convertion changes in PHP5 that I
haven't completely tried out yet, but that's a different issue.

Apologies Zurab, I didn't see your previous post regarding this issue and
to make it worse, I misread / misunderstood your point above initially.. I
now see that you weren't infacting asking _how_ to do the comparison of an
INT =)

Regards,

Ian

--
Ian.H
digiServ Network
London, UK
http://digiserv.net/

[Garp]

"Brian" <us*****@juliet remblay.com.inv alid> wrote in message
news:10******** *****@corp.supe rnews.com...

I must admit, I'm confused. I've been using the following code:

if ($_POST['referringpage'] <> 'catalogue') {
header("Locatio n: etc."

If there's no post variable 'referringpage' , I don't get any warning.
How come? (I'm not complaining, just anxious to avoid future problems.)

Try putting error_reporting (E_ALL) first and see what it does then, then
check your default error reporting level in your PHP.INI?

Garp

[Chung Leong]

"Zurab Davitiani" <ag*@mindless.c om> wrote in message
news:Hh******** *********@newss vr21.news.prodi gy.com...

I don't think it's *the* correct way. Call it "lousy examples" all you want. What if you are comparing the $_GET['x'] to an integer variable that's set
to 0 and not to string '0'?

Well, you can always use strcmp() or what not, but the bottomline is that
it's a string comparison. If the comparison is to a variable then you cast
the value into a string, that's all.

The point here is that using isset() does not automatically resolve
potential ambiguity. If it matters whether the user enter an empty string or
'0', then check for it explicitly with strlen(@$_GET['x']) > 0. If it
matters whether the variable is present, then use isset().
--
Obey the Clown - http://www.conradish.net/bobo/

[Zurab Davitiani]

Chung Leong wrote:

If you try these
if(@$_GET['x'] == 0)
if(@$_GET['x'] == false)
then they will evaluate to true, even though x key is undefined. You can try

with === but then you lose the flexibility of type conversion.

Well, those are pretty lousy examples, as they're both wrong. An empty
string will get cast to 0 on a comparison with a number, so
if($_GET['x']== 0) will give you unexpected behavior even if do a isset()
first. The correct way to check if the user actually entered '0' is
if($_GET['x'] == '0'), which works as expected even if you do
if(@$_GET['x'] == '0'). Likewise if(@$_GET['x'] == false) is equally
ambiguous, as GET variables are always strings. All it does is check
whether the user enter '0' or nothing.
Now I see you missed one detail. And I, in turn, missed that in my previous
reply to this post. You are assuming here the $_GET['x'] is defined (to an
empty string or 0), while I gave my examples for when x key is undefined.
The only case I can think of where there's a difference between a unset
and empty variable is a search page that submits to itself, where the
former means the user enters the page initially, while the latter means
s/he didn't enter a search criteria.

Yes, you give a specific example of what I was saying to begin with. So, in
more general sense, there could be a case of ?option=0 where you could have
an option-specific logic; and a default (when option is not specified):

if(@$_GET['option'] == 0)
//do option 0
else
//do default

In this case, if option is undefined, the else block will not execute
because the first condition is true; and you wouldn't get a PHP notice
either that option is not set.

So, I think we are saying the same thing.

[Chung Leong]

"Zurab Davitiani" <ag*@mindless.c om> wrote in message
news:L4******** ************@ne wssvr29.news.pr odigy.com...

Yes, you give a specific example of what I was saying to begin with. So, in more general sense, there could be a case of ?option=0 where you could have an option-specific logic; and a default (when option is not specified):

if(@$_GET['option'] == 0)
//do option 0
else
//do default

In this case, if option is undefined, the else block will not execute
because the first condition is true; and you wouldn't get a PHP notice
either that option is not set.

So, I think we are saying the same thing.

The same thing would happen if you do if(isset($_GET['option']) &&
$_GET['option'] == 0) and $_GET['option'] is empty. The point is that
isset() doesn't help here. What you need to do is if($_GET['option'] ==
'0')--which I call "the correct way" and which you refuse to believe,

[Zurab Davitiani]

Chung Leong wrote:

if(@$_GET['option'] == 0)
//do option 0
else
//do default

In this case, if option is undefined, the else block will not execute
because the first condition is true; and you wouldn't get a PHP notice
either that option is not set.

So, I think we are saying the same thing.
The same thing would happen if you do if(isset($_GET['option']) &&
$_GET['option'] == 0) and $_GET['option'] is empty. The point is that
isset() doesn't help here.

Actually, isset helps because in the example that I gave, $_GET['option'] is
*undefined* (not "empty" but only *undefined*) and the isset call will
evaluate to false. Without isset, the condition in my example will evaluate
to true.
What you need to do is if($_GET['option'] ==
'0')--which I call "the correct way" and which you refuse to believe,

Because once you determine that $_GET['option'] is *defined* then both of
these:

$_GET['option'] == '0'
$_GET['option'] == 0

will do exactly the same.

And because I believe in PHP's ability and flexibility of implicit type
conversion. Say you have a variable $x:

$x = 0; //say you got this value from a database numeric field

//now you have
if(@$_GET['option'] == $x)
// do stuff for option 0
else
// do default stuff

Now, again, if $_GET['option'] is *undefined* and you want to go to default
block in that case, you cannot use this logic; because if $_GET['option']
is *undefined* the first if condition will evaluate to true. You would have
to either:

1. use isset to determine whether $_GET['option'] defined or not first; OR,
2. like you said, convert $x explicitly to a string yourself or use a string
comparison function.

I wouldn't say the (2) is "the correct way" and the (1) is a "wrong way." In
fact, I prefer (1). But you may obviously disagree.

[Tim Streater]

In article <GJ************ ********@newssv r29.news.prodig y.com>,
Zurab Davitiani <ag*@mindless.c om> wrote:

Chung Leong wrote:

if(@$_GET['option'] == 0)
//do option 0
else
//do default

In this case, if option is undefined, the else block will not execute
because the first condition is true; and you wouldn't get a PHP notice
either that option is not set.

So, I think we are saying the same thing.

The same thing would happen if you do if(isset($_GET['option']) &&
$_GET['option'] == 0) and $_GET['option'] is empty. The point is that
isset() doesn't help here.

Actually, isset helps because in the example that I gave, $_GET['option'] is
*undefined* (not "empty" but only *undefined*) and the isset call will
evaluate to false. Without isset, the condition in my example will evaluate
to true.

What you need to do is if($_GET['option'] ==
'0')--which I call "the correct way" and which you refuse to believe,

Because once you determine that $_GET['option'] is *defined* then both of
these:

$_GET['option'] == '0'
$_GET['option'] == 0

will do exactly the same.

And because I believe in PHP's ability and flexibility of implicit type
conversion. Say you have a variable $x:

$x = 0; //say you got this value from a database numeric field

//now you have
if(@$_GET['option'] == $x)
// do stuff for option 0
else
// do default stuff

Now, again, if $_GET['option'] is *undefined* and you want to go to default
block in that case, you cannot use this logic; because if $_GET['option']
is *undefined* the first if condition will evaluate to true.

If option is undefined, then I would have thought that $_GET['option']
would also be undefined. If its undefined it cannot be equal to zero or
any other value, so why is the else clause not taken?

-- tim