Page 2 of 2

Posted: Thu May 31, 2007 4:56 pm
by John Cartwright
Firstly, its isset(), not is_set()..
Secondly, can you provide more information by empty() may introduce security holes. :?

Posted: Thu May 31, 2007 5:01 pm
by superdezign
Jcart wrote:Firstly, its isset(), not is_set()..
Secondly, can you provide more information by empty() may introduce security holes. :?
Oh Mordred, you've been told. :-p
In Mordred's defense though, maybe he was thinking along the lines of is_int and is_string.


And the bad thing about empty is that if you call empty on a value that is 0 (as an integer, not a string), empty will return true.

Posted: Fri Jun 01, 2007 3:05 am
by Mordred
isset() indeed, mea culpa. I'll try to abstain from posting when I'm sleepy :)
Secondly, can you provide more information by empty() may introduce security holes.
No, I didn't mean that, I mean that
security fixes may introduce new holes
. This follows from the "age barrier" between time-tested mature code and "young" new code. It's happened a lot before (to me as to many others) and is definitely a thing to watch out for when you're a newbie developer. And it's not just about security holes but about generic "old-skool" bugs/bugfixes as well.

To answer the question (with "regular bug" substituted for "security hole"), a value of 0 will return true for isset() and false for !empty(), buf of course you're well aware of that. As for how boss01 fixed the code - we can't tell without seeing it, that's why I ask him to post the new version again. Might be fixed, might have forgotten to plug a hole, might have introduced a new one. As I said, I've seen it happen before, it's just in the nature of the programming process.