Re: [PHP] Expected behaviour or bug?
17 sep 2012 kl. 10.50 skrev Camilo Sperberg:
Hello list, I have a little question with PHP's internal working. I've
managed to reduce the test to the following lines:
$globalVariable = 'i am a global variable';
function testFunction() {
global $globalVariable;
unset($globalVariable);
}
testFunction();
if(isset($globalVariable)) {
var_dump('global variable IS set');
} else {
var_dump('global variable is NOT set');
}
When executing the above test, you will get printed that the global variable
is set, despite unsetting it in the function. Is it really the intention to
unset a global variable inside a function locally or have I just happen to
found a little bug?
unreal4u-MBP:~ unreal4u$ php --version
PHP 5.3.13 with Suhosin-Patch (cli) (built: Jun 20 2012 17:05:20)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.3.0dev, Copyright (c) 2002-2012, by Derick Rethans
If it is expected behavior, is there any documentation on why this is done
this way?
Greetings and thanks.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Sometimes, it helps reading the manual...
http://lmgtfy.com/?q=php+unset+global
If a globalized variable is unset() inside of a function, only the local
variable is destroyed. The variable in the calling environment will retain the
same value as before unset() was called.
[...]
To unset() a global variable inside of a function, then use the$GLOBALS array
to do so:
Took about 1 minute to find out.
/frank
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Expected behaviour or bug?
On 17/09/2012, at 8:50 PM, Camilo Sperberg unrea...@gmail.com wrote:
Hello list, I have a little question with PHP's internal working. I've
managed to reduce the test to the following lines:
$globalVariable = 'i am a global variable';
function testFunction() {
global $globalVariable;
unset($globalVariable);
}
testFunction();
if(isset($globalVariable)) {
var_dump('global variable IS set');
} else {
var_dump('global variable is NOT set');
}
When executing the above test, you will get printed that the global variable
is set, despite unsetting it in the function. Is it really the intention to
unset a global variable inside a function locally or have I just happen to
found a little bug?
unreal4u-MBP:~ unreal4u$ php --version
PHP 5.3.13 with Suhosin-Patch (cli) (built: Jun 20 2012 17:05:20)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.3.0dev, Copyright (c) 2002-2012, by Derick Rethans
If it is expected behavior, is there any documentation on why this is done
this way?
Greetings and thanks.
That's expected, as per http://nz.php.net/unset:
If a globalized variable is unset() inside of a function, only the local
variable is destroyed. The variable in the calling environment will retain the
same value as before unset() was called.
---
Simon Welsh
Admin of http://simon.geek.nz/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Expected behaviour or bug?
On 17 sep. 2012, at 10:55, Frank Arensmeier farensme...@gmail.com wrote:
17 sep 2012 kl. 10.50 skrev Camilo Sperberg:
Hello list, I have a little question with PHP's internal working. I've
managed to reduce the test to the following lines:
$globalVariable = 'i am a global variable';
function testFunction() {
global $globalVariable;
unset($globalVariable);
}
testFunction();
if(isset($globalVariable)) {
var_dump('global variable IS set');
} else {
var_dump('global variable is NOT set');
}
When executing the above test, you will get printed that the global variable
is set, despite unsetting it in the function. Is it really the intention to
unset a global variable inside a function locally or have I just happen to
found a little bug?
unreal4u-MBP:~ unreal4u$ php --version
PHP 5.3.13 with Suhosin-Patch (cli) (built: Jun 20 2012 17:05:20)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.3.0dev, Copyright (c) 2002-2012, by Derick Rethans
If it is expected behavior, is there any documentation on why this is done
this way?
Greetings and thanks.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Sometimes, it helps reading the manual...
http://lmgtfy.com/?q=php+unset+global
If a globalized variable is unset() inside of a function, only the local
variable is destroyed. The variable in the calling environment will retain
the same value as before unset() was called.
[...]
To unset() a global variable inside of a function, then use the$GLOBALS
array to do so:
Took about 1 minute to find out.
/frank
Doh! Only thing I can say is that I tried searching but without any relevant
terms… Thanks and also thanks to Simon!
Greetings.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Expected behaviour or bug?
On Mon, Sep 17, 2012 at 8:57 PM, Camilo Sperberg unrea...@gmail.com wrote:
On 17 sep. 2012, at 10:55, Frank Arensmeier farensme...@gmail.com wrote:
17 sep 2012 kl. 10.50 skrev Camilo Sperberg:
Hello list, I have a little question with PHP's internal working. I've
managed to reduce the test to the following lines:
$globalVariable = 'i am a global variable';
function testFunction() {
global $globalVariable;
unset($globalVariable);
}
testFunction();
if(isset($globalVariable)) {
var_dump('global variable IS set');
} else {
var_dump('global variable is NOT set');
}
When executing the above test, you will get printed that the global
variable is set, despite unsetting it in the function. Is it really the
intention to unset a global variable inside a function locally or have I
just happen to found a little bug?
unreal4u-MBP:~ unreal4u$ php --version
PHP 5.3.13 with Suhosin-Patch (cli) (built: Jun 20 2012 17:05:20)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.3.0dev, Copyright (c) 2002-2012, by Derick Rethans
If it is expected behavior, is there any documentation on why this is done
this way?
Greetings and thanks.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Sometimes, it helps reading the manual...
http://lmgtfy.com/?q=php+unset+global
If a globalized variable is unset() inside of a function, only the local
variable is destroyed. The variable in the calling environment will retain
the same value as before unset() was called.
[...]
To unset() a global variable inside of a function, then use the$GLOBALS
array to do so:
Took about 1 minute to find out.
/frank
Doh! Only thing I can say is that I tried searching but without any relevant
terms… Thanks and also thanks to Simon!
Greetings.
Just a general note, the PHP manual is pretty good.
- Matijn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Possible foreach bug; seeking advice to isolate the problem
-Original Message-
From: Gary [mailto:php-gene...@garydjones.name]
Sent: Tuesday, October 19, 2010 11:38 PM
To: php-general@lists.php.net
Subject: [PHP] Re: Possible foreach bug; seeking advice to isolate the
problem
Jonathan Sachs wrote:
I've got a script which originally contained the following piece of
code:
foreach ( $objs as $obj ) {
do_some_stuff($obj);
}
When I tested it, I found that on every iteration of the loop the last
element of $objs was assigned the value of the current element.
I only had a few minutes to look at it, but here is my 2 Euro cents.
It only occurs when you have previously done
,
| foreach ( $objs as $obj ) {
|//anything or nothing here
| }
`
as described in the documentation.
That leaves me with the question: what is going wrong with foreach?
I'm trying to either demonstrate that it's my error, not the PHP
engine's, or isolate the problem in a small script that I can submit
with a bug report.
From the post you reference in the manual's comments:
$a = array('a', 'b','c');
foreach($a as $row){
//you don't have to do anything here
}
print_r($a);
foreach($a as $row){
echo br /.$row;
}
print_r($a);
This suffices.
I tried to eliminate the database by doing a var_export of the array
after I built it, then assigning the exported expression to a variable
immediately before the foreach. That broke the bug -- the loop
behaved correctly.
Yup. I guess whatever database code used previously was doing the
equivalent of the first foreach in the previous code snippet.
Can anyone make suggestions on this -- either insights into what's
wrong, or suggestions for producing a portable, reproducible example?
Better. I can tell you how to solve it:
$a = array('a', 'b','c');
foreach($a as $row){
//you don't have to do anything here
}
unset($row); // THIS IS KEY!
Shouldn't that be $row = null since unset will remove the last value, not
just removing the variable also, from the array whereas the $row = null will
tell the reference pointer that it doesn't point to a value.
print_r($a);
foreach($a as $row){
echo br /.$row;
}
print_r($a);
I admit though, it's not obvious, even from reading the manual, and is
definitely a bug in the sense it is unexpected behaviour. Documenting it
and calling it a feature is appalling.
Regards,
Tommy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Possible foreach bug; seeking advice to isolate the problem
On Wed, Oct 20, 2010 at 5:00 AM, Tommy Pham tommy...@gmail.com wrote: Shouldn't that be $row = null since unset will remove the last value, not just removing the variable also, from the array whereas the $row = null will tell the reference pointer that it doesn't point to a value. No, that would assign null to the last array element. References allow you to assign any value--including null--to the container they reference. Unsetting a reference breaks the reference without affecting whatever it references. $x = 5; $y = $x; $y = null; print_r($x); var_dump($x); -- NULL David
Re: [PHP] Re: Possible foreach bug; seeking advice to isolate the problem
On Wed, Oct 20, 2010 at 10:44 AM, David Harkness davi...@highgearmedia.com wrote: On Wed, Oct 20, 2010 at 5:00 AM, Tommy Pham tommy...@gmail.com wrote: Shouldn't that be $row = null since unset will remove the last value, not just removing the variable also, from the array whereas the $row = null will tell the reference pointer that it doesn't point to a value. No, that would assign null to the last array element. References allow you to assign any value--including null--to the container they reference. Unsetting a reference breaks the reference without affecting whatever it references. $x = 5; $y = $x; $y = null; print_r($x); var_dump($x); -- NULL David hmm.. About 8-9 years ago I did a project where I used the reference in a foreach loop as the OP. unset not only remove the variable but also the value in the array. I tried several methods at that time and ended up assigning null to get what I wanted without modifying the array. I'll have to dig up that project later to see. Thanks, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [RCD] [RCU] [bug of pecl pam ] I try to implement the change password plugin
On Sun, 25 Apr 2010 16:16:00 +0200, fakessh fake...@fakessh.eu wrote: On Sun, 25 Apr 2010 00:38:17 +0200, fakessh fake...@fakessh.eu wrote: On Sat, 24 Apr 2010 06:00:55 +0200, fakessh fake...@fakessh.eu wrote: On Thu, 22 Apr 2010 17:58:43 +0200, fakessh fake...@fakessh.eu wrote: On Thu, 22 Apr 2010 13:15:42 +0200, A.L.E.C a...@alec.pl wrote: fakessh wrote: [r...@r13151 ~]# diff --text -u /home/ftpchrootshell/fakessh/sasl.txt BTW, http://trac.roundcube.net/ticket/1486647 ;) pecl pam suffers from a known bug that prevents the proper use of driver pam that is right http://pecl.php.net/bugs/bug.php?id=16995 after further research it is necessary to type ctrl D. how to write in this code -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is it PHP Bug - memory leak ?
Hi, Pawel; On Sat, Dec 27, 2008 at 05:40, Pawel Rutkowski rut...@freelance-worker.net wrote: [snip!] But in PHP5 x64 I have errors like: /root/src/php-5.2.6/Zend/zend_hash.c(247) : Freeing 0x0E76BC50 (75 bytes), script=ext/session/tests/session_encode_variation5.phpt [Sat Dec 27 11:27:09 2008] Script: 'ext/session/tests/session_encode_variation5.phpt' /root/src/php-5.2.6/Zend/zend_vm_execute.h(3596) : Freeing 0x0E76B990 (71 bytes), script=ext/session/tests/session_encode_variation5.phpt /root/src/php-5.2.6/Zend/zend_hash.c(388) : Actual location (location was relayed) Please file a bug report on this with the reproduce cases at http://bugs.php.net/. There was a nearly identical case mentioned in the Zend forums[1] as found by Google, but no resolution was reached there. KEY: 1: http://www.zend.com/forums/index.php?t=msggoto=19257S=e5a6d1ca82291c880a9d85093afe1ee7 -- /Daniel P. Brown daniel.br...@parasane.net || danbr...@php.net http://www.parasane.net/ || http://www.pilotpig.net/ Unadvertised dedicated server deals, too low to print - email me to find out! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Is this a bug?
I actually must say we have a special kind of output buffering that saves all the content in an array like structure and outputs all content at the end. This way we managed to have our coders work in a rather C/C++ like way, where they can modify the rendered content anywhere in a script. The fact that the error gets detected twice is maybe a weirdness in our output handler, but as you guys already said, this should be detected actually as a parse error. About the editor, it's weird. We use Eclipse Europa (PDT Tools), because they integrate superb with our SVN2WEB development schema (instant web publish, SVN backup) and the error isn't highlighted in Eclipse. The manual tells nothing about such a thing. It's actually a weird glitch. Why: because if a PHP project decides it wants some weird control over the output buffer, like we do right here with our delay output until the script ends ideology, chances for such a typo to cause headaches is great. I can see projects rendered useless for a time, until the code is scanned for such a weirdness. All in all, thanks guys for the time you took testing this. It seems I must revise our output-handler, and do something to our Eclipse PDT set-up so it can detect this as an error. -Original Message- From: Thijs Lensselink [mailto:[EMAIL PROTECTED] Sent: Saturday, August 30, 2008 3:25 PM Cc: php-general@lists.php.net Subject: Re: [PHP] Is this a bug? Jochem Maas wrote: T Lensselink schreef: Catalin Zamfir Alexandru, DATAGRAM SRL wrote: Hello guys, I've been stalking on the list for some time. Didn't have anything to report/talk, until now. I have a code like this, maybe you guys can reproduce it, with output buffering started: Echo 'something'; Echo 'another thing'; Echo 'something br /'\; What happens is that ANYTHING that was echo'ed until that \, will not reach the buffer. Although, this should actually be a Parse Error, it isn't, it just echoes what was echoed after the god damned \. It took me two hours to find this typo in the code . ouch. don't forget you can do: $ php - l yourscript.php to test for syntax errors (the warning does show up with this). additionally a good syntax highlighting editor can help you to spot stuff like this ... anything to stop the eyes from bleeding :/ Can you guys reproduce the error? I can actually give you a link to the server where this code runs. The script doesn't cause a parse error Instead it throws a warning. 'PHP Warning: Unexpected character in input: '\' (ASCII=92) state=1 in' Don't think it's a bug. And the reason there's no syntax error is because the \ is a PHP escape character. is this character ever valid as an escape character outside of a string? if it is that's news to me and if it isn't then really it is a bug ... it should be a straight up parse error ... chances are that it's down to limitations in the lexer? the output buffer handler that seems to be swallowing the warning every second request now that is weird. I don't think it should be valid outside a string. But PHP seems to see this different. The only reason i could think of. Is that the \ somehow is a registered symbol. So it throws a non fatal E_COMPILE_ERROR. Could be a bug. That's for the guys on internals to decide. I'd also expect a parse error. With output buffering enabled i still get the same warning on every request. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?
Jochem Maas wrote: T Lensselink schreef: Catalin Zamfir Alexandru, DATAGRAM SRL wrote: Hello guys, I've been stalking on the list for some time. Didn't have anything to report/talk, until now. I have a code like this, maybe you guys can reproduce it, with output buffering started: Echo 'something'; Echo 'another thing'; Echo 'something br /'\; What happens is that ANYTHING that was echo'ed until that \, will not reach the buffer. Although, this should actually be a Parse Error, it isn't, it just echoes what was echoed after the god damned \. It took me two hours to find this typo in the code . ouch. don't forget you can do: $ php - l yourscript.php to test for syntax errors (the warning does show up with this). additionally a good syntax highlighting editor can help you to spot stuff like this ... anything to stop the eyes from bleeding :/ Can you guys reproduce the error? I can actually give you a link to the server where this code runs. The script doesn't cause a parse error Instead it throws a warning. 'PHP Warning: Unexpected character in input: '\' (ASCII=92) state=1 in' Don't think it's a bug. And the reason there's no syntax error is because the \ is a PHP escape character. is this character ever valid as an escape character outside of a string? if it is that's news to me and if it isn't then really it is a bug ... it should be a straight up parse error ... chances are that it's down to limitations in the lexer? the output buffer handler that seems to be swallowing the warning every second request now that is weird. I don't think it should be valid outside a string. But PHP seems to see this different. The only reason i could think of. Is that the \ somehow is a registered symbol. So it throws a non fatal E_COMPILE_ERROR. Could be a bug. That's for the guys on internals to decide. I'd also expect a parse error. With output buffering enabled i still get the same warning on every request. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?
On Fri, 2008-08-29 at 10:40 +0300, Catalin Zamfir Alexandru, DATAGRAM SRL wrote: Echo 'something'; Echo 'another thing'; Echo 'something br /'\; I got the following output in both php5 and php4: Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/rob/bleh.php on line 7 somethinganother thingsomething br / You might want to crank up your error reporting. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?
Catalin Zamfir Alexandru, DATAGRAM SRL wrote: Hello guys, I've been stalking on the list for some time. Didn't have anything to report/talk, until now. I have a code like this, maybe you guys can reproduce it, with output buffering started: Echo 'something'; Echo 'another thing'; Echo 'something br /'\; What happens is that ANYTHING that was echo'ed until that \, will not reach the buffer. Although, this should actually be a Parse Error, it isn't, it just echoes what was echoed after the god damned \. It took me two hours to find this typo in the code . Can you guys reproduce the error? I can actually give you a link to the server where this code runs. The script doesn't cause a parse error Instead it throws a warning. 'PHP Warning: Unexpected character in input: '\' (ASCII=92) state=1 in' Don't think it's a bug. And the reason there's no syntax error is because the \ is a PHP escape character. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Is this a bug?
I'm using a custom ob_handler (it's a MVC framework, we need this handler). The ironic thing is that, executed once, the error doesn't show. Executed twice, the error you're talking about shows. Executed 3rd ... the same as the first execution. And I have my error_reporting to E_ALL. This happens ONLY on this kind of error, any other type of error gets reported every time. Do you have any ideea what this error type is? E_WARNING? Maybe I missed something ... And, shouldn't this be a parse error? Rather than a warning? -Original Message- From: Robert Cummings [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 10:56 AM To: Catalin Zamfir Alexandru, DATAGRAM SRL Cc: php-general@lists.php.net Subject: Re: [PHP] Is this a bug? On Fri, 2008-08-29 at 10:40 +0300, Catalin Zamfir Alexandru, DATAGRAM SRL wrote: Echo 'something'; Echo 'another thing'; Echo 'something br /'\; I got the following output in both php5 and php4: Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/rob/bleh.php on line 7 somethinganother thingsomething br / You might want to crank up your error reporting. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?
T Lensselink schreef: Catalin Zamfir Alexandru, DATAGRAM SRL wrote: Hello guys, I've been stalking on the list for some time. Didn't have anything to report/talk, until now. I have a code like this, maybe you guys can reproduce it, with output buffering started: Echo 'something'; Echo 'another thing'; Echo 'something br /'\; What happens is that ANYTHING that was echo'ed until that \, will not reach the buffer. Although, this should actually be a Parse Error, it isn't, it just echoes what was echoed after the god damned \. It took me two hours to find this typo in the code . ouch. don't forget you can do: $ php - l yourscript.php to test for syntax errors (the warning does show up with this). additionally a good syntax highlighting editor can help you to spot stuff like this ... anything to stop the eyes from bleeding :/ Can you guys reproduce the error? I can actually give you a link to the server where this code runs. The script doesn't cause a parse error Instead it throws a warning. 'PHP Warning: Unexpected character in input: '\' (ASCII=92) state=1 in' Don't think it's a bug. And the reason there's no syntax error is because the \ is a PHP escape character. is this character ever valid as an escape character outside of a string? if it is that's news to me and if it isn't then really it is a bug ... it should be a straight up parse error ... chances are that it's down to limitations in the lexer? the output buffer handler that seems to be swallowing the warning every second request now that is weird. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Looks like a bug with Smarty
got the answer from you clive :) Thanks
On Jan 18, 2008 1:02 PM, clive [EMAIL PROTECTED] wrote:
if ($question == 'php')
domail('phplist',$question);
if ($question == 'smarty')
domail('smartylist',$question);
Hi All,
I using html_options smarty tag to output an associative array in select
drop down.
Here a sample associative array:
array(5) {
[CN-PEK-KEJ]=
array(1) {
[198]=
string(7) TechTst
}
[IE-DUB-GAS]=
array(2) {
[177]=
string(10) store room
[39]=
string(10) TechStop 2
}
[UK-LON-BEL]=
array(1) {
[88]=
string(16) TechStop-LON-BEL
}
[IE-DUB-GOR]=
array(1) {
[159]=
string(10) TechStop 1
}
[US-NYC-9TH]=
array(1) {
[194]=
string(12) TestTechStop
}
}
and the syntax I have used to output this was:
{html_options name='locationId' options=$locations
selected=$selectedLocation}
where in I assign $selectedLocation with one of the options after
selecting
them.
Even after everything being right, the option thats been selected is not
set
but it again goes back to show the first option after submit.
Looks like either smarty misinterprets this selected option or is there
something wrong from my end.
Cheers
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Mark is on the way to make a Mark in your hearts
-
Fight back spam! Download the Blue Frog.
http://www.bluesecurity.com/register/s?user=Z290aHNfMzE4OTg2NA%3D%3D
Re: [PHP] Looks like a bug with Smarty
You'll have to take this up with the Smarty folks, as it's very
smarty-specific, and not (PHP-)General at all...
On Fri, January 18, 2008 12:16 am, GoWtHaM NaRiSiPaLli wrote:
Hi All,
I using html_options smarty tag to output an associative array in
select
drop down.
Here a sample associative array:
array(5) {
[CN-PEK-KEJ]=
array(1) {
[198]=
string(7) TechTst
}
[IE-DUB-GAS]=
array(2) {
[177]=
string(10) store room
[39]=
string(10) TechStop 2
}
[UK-LON-BEL]=
array(1) {
[88]=
string(16) TechStop-LON-BEL
}
[IE-DUB-GOR]=
array(1) {
[159]=
string(10) TechStop 1
}
[US-NYC-9TH]=
array(1) {
[194]=
string(12) TestTechStop
}
}
and the syntax I have used to output this was:
{html_options name='locationId' options=$locations
selected=$selectedLocation}
where in I assign $selectedLocation with one of the options after
selecting
them.
Even after everything being right, the option thats been selected is
not set
but it again goes back to show the first option after submit.
Looks like either smarty misinterprets this selected option or is
there
something wrong from my end.
Cheers
--
Mark is on the way to make a Mark in your hearts
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Looks like a bug with Smarty
if ($question == 'php')
domail('phplist',$question);
if ($question == 'smarty')
domail('smartylist',$question);
Hi All,
I using html_options smarty tag to output an associative array in select
drop down.
Here a sample associative array:
array(5) {
[CN-PEK-KEJ]=
array(1) {
[198]=
string(7) TechTst
}
[IE-DUB-GAS]=
array(2) {
[177]=
string(10) store room
[39]=
string(10) TechStop 2
}
[UK-LON-BEL]=
array(1) {
[88]=
string(16) TechStop-LON-BEL
}
[IE-DUB-GOR]=
array(1) {
[159]=
string(10) TechStop 1
}
[US-NYC-9TH]=
array(1) {
[194]=
string(12) TestTechStop
}
}
and the syntax I have used to output this was:
{html_options name='locationId' options=$locations
selected=$selectedLocation}
where in I assign $selectedLocation with one of the options after selecting
them.
Even after everything being right, the option thats been selected is not set
but it again goes back to show the first option after submit.
Looks like either smarty misinterprets this selected option or is there
something wrong from my end.
Cheers
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] is this a bug?
On 8/20/07, Augusto Morais [EMAIL PROTECTED] wrote:
I dont know what is happening...
Can somebody clarify the situation for me?
here is the situation:
i have 3 files:
class.php
foo.php
bar.php
// - class.php
class globalactions {
function include_file($module) {
if ($module) {
return
(modules/.$module./templates/.$module..php);
} else { return include(modules/main/templates/index.php); }
}
}
// - foo.php
include lib/clients.class.php;
$clients = new clients(); //instatiating the clients class
// - bar.php
include 'class.php';
$globalactions = new globalactions ();
include $globalactions-include_file(foo); //return -
modules/foo/templates/foo.php
var_dump($clients); //will return the object
OK. All this works. but i want make some changes.
Well.. What i want to do is this:
class.php:
change the line:
return (modules/.$module./templates/.$module..php);
to:
return include (modules/.$module./templates/.$module..php);
and in the bar.php:
// - bar.php
include 'class.php';
$globalactions = new globalactions ();
$globalactions-include_file(foo); //return - include
modules/foo/templates/foo.php // OK. This works.
var_dump($clients); //i dont get the object here. I got NULL!!! why?!?!!?
What is happening?
This is because in the second example, you're including the file in a
different scope than the first example. The file included (and so all
variables etc. declared in it) will be added to the scope where the
include is.
This manual page should help you:
http://www.php.net/manual/en/language.variables.scope.php
Tijnema
--
If this is a mailing list: DO NOT TOP POST! why?:
http://www.caliburn.nl/topposting.html
Vote for PHP Color Coding in Gmail! - http://gpcc.tijnema.info
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] is this a bug?
On 8/20/07, aflavio [EMAIL PROTECTED] wrote:
Strange..
I'm return a include..
Not exactly... you're returning the return value of an include.
Take this:
var.php:
?php
return bar;
?
foo.php
?php
function include_bar() {
return include bar.php
}
echo include_bar(); // echoes bar
the file will be included in the scope of the class? Because this i cant use
the variables declared in the file ? all declared in the file only can be
access from the method that i use to include the class file.
example:
snip some code
Am i right?
thanks
ps.: Sorry by the english.
Augusto Morais
Well, you're quite close, but you expect something different from the
return... Like I said above.
Tijnema
ps. I don't really care about your english, but top posting is
annoying. Read the site in my signature to know why. Also snipping
irrelevant parts of the original message is important.
pps. Make sure you use the Reply to all button when making a reply
to the list, as for now, I was the only one who got your message. If
you don't have a Reply to all button, make sure you put the php list
in the to or cc address.
--
If this is a mailing list: DO NOT TOP POST! why?:
http://www.caliburn.nl/topposting.html
Vote for PHP Color Coding (aka Syntax Highlighting) in Gmail! -
http://gpcc.tijnema.info
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] is this a bug?
On Mon, 20 Aug 2007 02:24:49 -0300, Augusto Morais [EMAIL PROTECTED] wrote:
I dont know what is happening...
Can somebody clarify the situation for me?
here is the situation:
i have 3 files:
class.php
foo.php
bar.php
// - class.php
class globalactions {
function include_file($module) {
if ($module) {
return
(modules/.$module./templates/.$module..php);
} else { return include(modules/main/templates/index.php); }
}
}
// - foo.php
include lib/clients.class.php;
$clients = new clients(); //instatiating the clients class
// - bar.php
include 'class.php';
$globalactions = new globalactions ();
include $globalactions-include_file(foo); //return -
modules/foo/templates/foo.php
var_dump($clients); //will return the object
OK. All this works. but i want make some changes.
Well.. What i want to do is this:
class.php:
change the line:
return (modules/.$module./templates/.$module..php);
to:
return include (modules/.$module./templates/.$module..php);
and in the bar.php:
// - bar.php
include 'class.php';
$globalactions = new globalactions ();
$globalactions-include_file(foo); //return - include
modules/foo/templates/foo.php // OK. This works.
var_dump($clients); //i dont get the object here. I got NULL!!! why?!?!!?
What is happening?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
No this is not a bug. And it also has nothing todo with scoping.
The object client returns NULL. This can only happen if the object is not
instantiated.
I guess the foo.php file is not included at all.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] This is a bug?
On 8/20/07, Augusto Morais [EMAIL PROTECTED] wrote: [snip!] // - foo.php include lib/clients.class.php; $clients = new clients(); //instatiating the clients class [snip again!] var_dump($clients); //i dont get the object here. I got NULL!!! why?!?!!? problem: When the method(include_file) return include FILE the $client object stay NULL but when the same method only return FILE : include $globalactions-include_file(foo); the $client object isnt empty. Augusto, I read your code over several times where is the clients(); code, and how is that returned to the script? I couldn't find it anywhere in there, and I didn't see an explanation. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 Hey, PHP-General list 50% off for life on web hosting plans $10/mo. or more at http://www.pilotpig.net/. Use the coupon code phpgeneralaug07 Register domains for about $0.01 more than what it costs me at http://domains.pilotpig.net/. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP 5.2.0 Session Handling Bug? Can someone test this please?
Colin Guthrie wrote: Hi, I've noticed a bug with PHP 5.2.0 when dealing with sessions and posting quite large forms. I've attached a file that highlights the bug. Can people test this please and if it is confirmed i'll post upsteam. Just want to rule out my distro's packaging being at fault I am using the suochsim, soouishm, soushim ach the security patch thing, so that may be what is at fault here. Anyway, I don't think the data itself is to blame but I didn't fiddle too much with it as I didn't see the point. I've tested this on PHP 5.1.6 and it is not affected. I should also say that I'm 64-bit everything if that makes a difference. If other people do NOT get this bug, I'd appreciate it if they could say their arch too (also if it's windoze/osx etc.). I'm using Mandriva Cooker FWIW (and no this is not a production box... wouldn't run Cooker on that!!) Col. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: PHP 5.2.0 Session Handling Bug? Can someone test this please?
Have you checked your error_log? I've had this problem when the wrong permissions were set on /var/lib/php/session which meant PHP couldn't write it's session files and hence generated a new ID each time. The error_log will tell you if this is the case. Edward Colin Guthrie wrote: Hi, I've noticed a bug with PHP 5.2.0 when dealing with sessions and posting quite large forms. I've attached a file that highlights the bug. Can people test this please and if it is confirmed i'll post upsteam. Just want to rule out my distro's packaging being at fault I am using the suochsim, soouishm, soushim ach the security patch thing, so that may be what is at fault here. Anyway, I don't think the data itself is to blame but I didn't fiddle too much with it as I didn't see the point. I've tested this on PHP 5.1.6 and it is not affected. I should also say that I'm 64-bit everything if that makes a difference. If other people do NOT get this bug, I'd appreciate it if they could say their arch too (also if it's windoze/osx etc.). I'm using Mandriva Cooker FWIW (and no this is not a production box... wouldn't run Cooker on that!!) Col. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP 5.2.0 Session Handling Bug? Can someone test this please?
Frank J. Schima wrote: The ID never changed for me. PHP 5.2.0 Apache 1.3.33 Mac OS X 10.4.8 Cheers mate. I guess that could mean its: * Apache 2 thing * x86_64 thing * suhosin thing * mandriva thing More tests to narrow those down would be appreciated if anyone has appropriate installs to hand. Col. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP 5.2.0 Session Handling Bug? Can someone test this please?
Edward Kay wrote: Have you checked your error_log? I've had this problem when the wrong permissions were set on /var/lib/php/session which meant PHP couldn't write it's session files and hence generated a new ID each time. The error_log will tell you if this is the case. No, but the problem doesn't exhibit those characteristics. Sessions work generally, and I can log in to my application and do certain things that require a working session etc. It's only when I used a page that posts a large amount of data that the problem is apparent. I've tried it with overridden session handling functions that store session in a db too with the same results. In my test here, you can do a GET request several times and get the same id, it's only when you do the POST request that the bug is presented (at least for me). Cheers for the suggestion tho'. Col. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is it a bug ?
ok this is returning the retrived data from open sockets : http://pastebin.com/716768 this is returning an empty string : http://pastebin.com/716767 On 5/14/06, chris smith [EMAIL PROTECTED] wrote: On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: Code 1 : - var_dump(stream_get_contents($rr)); - Output 1 - string(185) HTTP/1.1 202 Accepted Server: Apache2 Content-Length: 24 Connection: close Content-type: text/html Pragma: no-cache Cache-Control: no-cache 0: Accepted for delivery - Code 2 : - $x = stream_get_contents($rr); var_dump($x); - Output 2 - string(0) - Am i wrong ? Without seeing all of the code, we can't tell anything from that. Post it in http://pastebin.com and send us a url. -- Postgresql php tutorials http://www.designmagick.com/
Re: [PHP] Is it a bug ?
On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: ok this is returning the retrived data from open sockets : http://pastebin.com/716768 this is returning an empty string : http://pastebin.com/716767 it's not a bug :) i shoul wait for stream to be returned, i use : while(($buff = stream_get_contents($socket[$i]))==); echo $buff; it takes sometime to receive stream from socket, is it the best way (dont think so) to wait for stream ? On 5/14/06, chris smith [EMAIL PROTECTED] wrote: On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: Code 1 : - var_dump(stream_get_contents($rr)); - Output 1 - string(185) HTTP/1.1 202 Accepted Server: Apache2 Content-Length: 24 Connection: close Content-type: text/html Pragma: no-cache Cache-Control: no-cache 0: Accepted for delivery - Code 2 : - $x = stream_get_contents($rr); var_dump($x); - Output 2 - string(0) - Am i wrong ? Without seeing all of the code, we can't tell anything from that. Post it in http://pastebin.com and send us a url. -- Postgresql php tutorials http://www.designmagick.com/
Re: [PHP] Is it a bug ?
$var = file (http://www.some.server.net:someport;); then $var=explode ... bla bla.. that never crash. cheers, cajbecu On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: ok this is returning the retrived data from open sockets : http://pastebin.com/716768 this is returning an empty string : http://pastebin.com/716767 it's not a bug :) i shoul wait for stream to be returned, i use : while(($buff = stream_get_contents($socket[$i]))==); echo $buff; it takes sometime to receive stream from socket, is it the best way (dont think so) to wait for stream ? On 5/14/06, chris smith [EMAIL PROTECTED] wrote: On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: Code 1 : - var_dump(stream_get_contents($rr)); - Output 1 - string(185) HTTP/1.1 202 Accepted Server: Apache2 Content-Length: 24 Connection: close Content-type: text/html Pragma: no-cache Cache-Control: no-cache 0: Accepted for delivery - Code 2 : - $x = stream_get_contents($rr); var_dump($x); - Output 2 - string(0) - Am i wrong ? Without seeing all of the code, we can't tell anything from that. Post it in http://pastebin.com and send us a url. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is it a bug ?
cajbecu, am talking about non-blocking sockets, that's a simple blocking socket On 5/14/06, cajbecu [EMAIL PROTECTED] wrote: $var = file (http://www.some.server.net:someport;); then $var=explode ... bla bla.. that never crash. cheers, cajbecu On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: ok this is returning the retrived data from open sockets : http://pastebin.com/716768 this is returning an empty string : http://pastebin.com/716767 it's not a bug :) i shoul wait for stream to be returned, i use : while(($buff = stream_get_contents($socket[$i]))==); echo $buff; it takes sometime to receive stream from socket, is it the best way (dont think so) to wait for stream ? On 5/14/06, chris smith [EMAIL PROTECTED] wrote: On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: Code 1 : - var_dump(stream_get_contents($rr)); - Output 1 - string(185) HTTP/1.1 202 Accepted Server: Apache2 Content-Length: 24 Connection: close Content-type: text/html Pragma: no-cache Cache-Control: no-cache 0: Accepted for delivery - Code 2 : - $x = stream_get_contents($rr); var_dump($x); - Output 2 - string(0) - Am i wrong ? Without seeing all of the code, we can't tell anything from that. Post it in http://pastebin.com and send us a url. -- Postgresql php tutorials http://www.designmagick.com/
Re: [PHP] Is it a bug ?
On Sun, May 14, 2006 8:49 am, Fourat Zouari wrote: On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: it's not a bug :) i shoul wait for stream to be returned, i use : while(($buff = stream_get_contents($socket[$i]))==); echo $buff; it takes sometime to receive stream from socket, is it the best way (dont think so) to wait for stream ? Well, you could try to make the other end of the stream pump the data out faster... If you have $socket[$i] then you proably have multiple sockets open, in which case methinks you want http://php.net/stream_select which polls a bunch of streams in one go and gives you data from whatever stream is ready. In older PHP versions, where that function is not available, you can hack this with something not unlike: http://www.l-i-e.com/FeedMulti/ -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is it a bug ?
On 5/14/06, Fourat Zouari [EMAIL PROTECTED] wrote: Code 1 : - var_dump(stream_get_contents($rr)); - Output 1 - string(185) HTTP/1.1 202 Accepted Server: Apache2 Content-Length: 24 Connection: close Content-type: text/html Pragma: no-cache Cache-Control: no-cache 0: Accepted for delivery - Code 2 : - $x = stream_get_contents($rr); var_dump($x); - Output 2 - string(0) - Am i wrong ? Without seeing all of the code, we can't tell anything from that. Post it in http://pastebin.com and send us a url. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is it a bug of CakePHP?
Pham Huu Le Quoc Phuc a écrit : I catch an error, could you tell me if you have some ideas? Error message: Undefined index: start_date in c:\Inetpub\wwwroot\Cake\app\controllers\dsptrainings_controller.php on line 33 PHP is telling you that what you are trying to access doesn't exist. This is is a matter of you trying to access something that doesn't exist. So the question is, what does $data look like? My suggestion is to print_r($data) to see. Perhaps findBySql() doesn't return the results as an associative array? Or since you're sending a query for only one record, it doesn't send a 2-dimensional array back? Maybe your start date can be accessed simply by $data['start_date']? I don't know, I don't use CakePHP. Again, print your $data variable to the screen to find out what it contains. Consider this to be a powerful tool in your bag of debugging tricks. I print variables to the screen all the time to find out what's wrong. In fact, I'll do it in a two step process: print_r($my_variable); die(hrfilename.php:line_num); The first line prints the variable I'm after to the screen. The second line kills the script, but outputs the text I send it first. So it draws a horizontal rule across the page, and then prints out the file name and line number that the script was killed at. So if I'm tracing a particularly elusive bug, I can place these two lines in various places across my app, and walk through it step by step. The important part is knowing the filename and location of your debugging marks, so that you can clean them up easily. HTH, John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is it a bug of CakePHP?
Pham Huu Le Quoc Phuc a écrit :
I catch an error, could you tell me if you have some ideas?
class Dsptraining extends AppModel
{
function GetDsptrainings()
{
return $this-findBySql(select max(start_date) start_date from
tbl_dsptrainings);
}
}
did you try your sql query directly using sql ?
try this one :
select max(start_date) as start_date from tbl_dsptrainings
N F
class DsptrainingsController extends AppController
{
function index()
{
$data = $this-Dsptraining-GetDsptrainings();
echo $data[0]['start_date'];
}
}
Error message: Undefined index: start_date in
c:\Inetpub\wwwroot\Cake\app\controllers\dsptrainings_controller.php on line
33
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is it a bug of CakePHP?
Thanks for relying!
But, Do not have anyway to solve this problem.
- Original Message -
From: nicolas figaro [EMAIL PROTECTED]
To: php-general@lists.php.net
Sent: Friday, April 07, 2006 3:49 PM
Subject: Re: [PHP] Is it a bug of CakePHP?
Pham Huu Le Quoc Phuc a écrit :
I catch an error, could you tell me if you have some ideas?
class Dsptraining extends AppModel
{
function GetDsptrainings()
{
return $this-findBySql(select max(start_date) start_date
from
tbl_dsptrainings);
}
}
did you try your sql query directly using sql ?
try this one :
select max(start_date) as start_date from tbl_dsptrainings
N F
class DsptrainingsController extends AppController
{
function index()
{
$data = $this-Dsptraining-GetDsptrainings();
echo $data[0]['start_date'];
}
}
Error message: Undefined index: start_date in
c:\Inetpub\wwwroot\Cake\app\controllers\dsptrainings_controller.php on
line
33
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP 4.4.1 array_set_current bug?
On Fri, Dec 16, 2005 at 09:09:08AM -0500, Eric Butera wrote:
Hello all,
I have an image gallery script I created and I seem to be having some
difficulties with it. I am using this script on many different platforms
and different PHP versions. I have tried it on 4.4.0 (linux) and
4.3.11(entrophy osx). The problem is with PHP version
4.4.1 from what I can tell. That is what I am emailing for, to verify. =)
The problem is this function:
function array_set_current($array, $key) {
reset($array);
while(current($array)) {
if (key($array) == $key) {
break;
} // if
next($array);
} // while
} // function
On 4.4.0 and 4.3.11 I can pass an array and key and it will match the key
and break perfectly. Recently one of our servers upgraded to 4.4.1. This
script was working previously and now does not. I ended up echoing out the
value of key(). On 4.4.1 the key is always 0. Next() does not goto the next
key. On 4.4.0 and 4.3.11 the next() works fine.
well, this works perfectly fine on php 4.4.1:
?php
$a = array('a' = 'a', 'b' = 'b', 'c' = 'c');
array_set_current($a, 'b');
var_dump(current($a));
// prints string(1) b
Curt.
--
cat .signature: No such file or directory
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: XmlWriter::writeDTD bug...
Jared Williams wrote:
Hi,
$writer = new XmlWriter();
...
$writer-writeDtd('html', '-//W3C//DTD XHTML 1.0 Strict//EN',
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd');
produces no whitespace between the public system ids like...
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0
Strict//ENhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
Has anyone got a workaround for this problem?
libxml bug. Add $writer-setIndent(TRUE); before the writeDTD
call (can revert it back right after if you dont want
indenting). This will force whitespace insertion between the
two - not pretty but its a workaround.
PS.
Yeah, thought it was libxml, hence didn't file a pecl bug report. But
there does seem a problem with this method as can't
just have a publicId or a systemId, libxml function uses NULL as a parameter to
specify which id you don't want to use. Which we've
lost with the PHP wrapper, as can only specify two strings.
And when pecl.php.net was reachable I'll report it.
Jared
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: XmlWriter::writeDTD bug...
Jared Williams wrote: PS. Yeah, thought it was libxml, hence didn't file a pecl bug report. But there does seem a problem with this method as can't just have a publicId or a systemId, libxml function uses NULL as a parameter to specify which id you don't want to use. Which we've lost with the PHP wrapper, as can only specify two strings. Have you tried passing NULL for publicId? :) And systemId can only be NULL if there is no publicId (publicId requires a systemId). Rob -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: XmlWriter::writeDTD bug...
Jared Williams wrote: PS. Yeah, thought it was libxml, hence didn't file a pecl bug report. But there does seem a problem with this method as can't just have a publicId or a systemId, libxml function uses NULL as a parameter to specify which id you don't want to use. Which we've lost with the PHP wrapper, as can only specify two strings. Have you tried passing NULL for publicId? :) And systemId can only be NULL if there is no publicId (publicId requires a systemId). Ah, yes, I blame it time, 3am, when was tinkering with XmlWriter :) Jared -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] if statement probable bug
Hello TheI2eptile, Thursday, March 24, 2005, 2:05:14 PM, you wrote: T So here is what I would call a bug, but maybe it's thought to be so: Try it with strict (data-type) comparisons, i.e.: if ($var === AS) Then you won't get the bug. Best regards, Richard Davey -- http://www.launchcode.co.uk - PHP Development Services I do not fear computers. I fear the lack of them. - Isaac Asimov -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] if statement probable bug
TheI2eptile wrote:
Probably this is the wrong place to put this but I couldn't search for
not at all the wrong place, having said that the only thing probable with
regard
to you/your post is that you are not fully aware of the nature of data types in
php and the way auto-typecasting works (in terms of precedence and
conversion)...
which is not surprising, most people get bitten by this at some time :-) because
often when looking at the behaviour from the point of view of other
langs (or as a complete beginner) the logic behind it may not seem at all
logical...
I recommend searching for some more info on (auto)typecasting in php,
by the sounds of things you're capable of grokking the whys and wherefores
without
much trouble :-)
the bug and what I saw in the bugs newsgroup was a bit strange and seem
to be a log for the bugs forms.
So here is what I would call a bug, but maybe it's thought to be so:
?php
$var1 = 0;
$var2 = AS;
if($var1 == AS){
echo brWhy is this printed;
}
int has higher precendence... therefore AS is converted to an int
... AS when converted to an int is zero... the order of the operands does not
matter in this case, try the following one liner:
?php var_dump( (0 == AS), (AS == 0) ); ?
if(0 == AS){
echo brAt least this should not be printed;
}
same rules applies here.
if($var2 == AS){
echo brOnly this should;
}
?
I didn't expect it. I use php 5.02 and have the zend debugger installed.
Does anybody see every echo and finds this strange in a typeless language?
php is not typeless! its dynamically typed.
I wonder if there are typeless langs at all :-)
btw: yes I see every echo, no I don't find it strange (anymore!)
as someone else already mentioned: use the strict equality operator (===) to
tell php not to do auto-typecasting on the vars you want to check for equality.
rgds,
Jochem
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?!!! I cna't believe! Sorry, if im wrong...
No
news.php.net wrote:
?
class A
{
var $name;
function A($str)
{
$this-name = $str;
}
}
$arr = array();
//Put to array to objects of class A,
// where their attribute A::a is assigned a different value
//objects are assigned to an array by reference
$a = new A(qaz);
$arr[0] = $a;
$arr[0] and $a reference now the same variable
$a = new A(wsx);
by changing $a you also changed $arr[0]
$arr[1] = $a;
now $a, $arr[0] and $arr[1] reference the same variable, they just have
different names.
More:
http://sk.php.net/manual/en/language.variables.php
http://sk.php.net/manual/en/language.references.php
//But watch the output!!!
// It is (qaz)(qaz), which means that the attribute of a first
// object assigned to array is outputted!!! WHY?!?!!!
foreach($arr as $a)
{
echo (.$a-name.);
}
?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?!!! I cna't believe! Sorry, if im wrong...
No
news.php.net wrote:
?
class A
{
var $name;
function A($str)
{
$this-name = $str;
}
}
$arr = array();
//Put to array to objects of class A,
// where their attribute A::a is assigned a different value
//objects are assigned to an array by reference
$a = new A(qaz);
$arr[0] = $a;
$arr[0] and $a reference now the same variable
$a = new A(wsx);
by changing $a you also changed $arr[0]
No. referencs are not pointers! Here in $a = new A(wsx) I assign $a
by reference, and now $a references the different location, and $arr[0]
references the same. Assigning $a by references doesnt affect $arr[0],
though the pointed to the same location before...
After all this is the prove:
This is my previous assignment code:
class A
{
var $name;
function A($str)
{
$this-name = $str;
}
}
$arr = array();
//Put to array to objects of class A,
// where their attribute A::a is assigned a different value
//objects are assigned to an array by reference
$a = new A(qaz);
$arr[0] = $a;
$a = new A(wsx);
$arr[1] = $a;
//HERE IS THE PROVE
print_r($arr);
//Watch the OUTPUT... there are DIFFERENT objects laying in the array! This
is the point of my question...
// But if you do this:
foreach($arr as $a)
{
echo (.$a-name.);
}
// You see that iterating the objects it somehow references the same
object...
// or the same 'name' attrribute of the first object in the array...
$arr[1] = $a;
now $a, $arr[0] and $arr[1] reference the same variable, they just have
different names.
More:
http://sk.php.net/manual/en/language.variables.php
http://sk.php.net/manual/en/language.references.php
//But watch the output!!!
// It is (qaz)(qaz), which means that the attribute of a first
// object assigned to array is outputted!!! WHY?!?!!!
foreach($arr as $a)
{
echo (.$a-name.);
}
?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?!!! I cna't believe! Sorry, if im wrong...
I did a little experimenting, and it looks like foreach is misbehaving,
but may I just don't get it, anyway check this out
(my php version and output are below):
class A { var $name; function A($str) { $this-name = $str; } }
// does not work as expected.
$arr = array();
$a = new A(qaz);
$arr[0] = $a; unset($a);
$a = new A(wsx); print_r($a);
$arr[1] = $a; print_r($arr[1]);
print_r($arr);
foreach($arr as $a) { echo (.$a-name.); }
echo \n; //^-- I thought this might be the problem, hence:
foreach($arr as $b) { echo (.$b-name.); }
echo \n--\n;
// works as expected
$arrB = array();
$arrB[0] = new A(qaz);
$arrB[1] = new A(wsx);
print_r($arrB);
foreach($arrB as $c) { echo (.$c-name.); }
echo \n--\n;
// works as expected
$arrC = array();
$f = new A(qaz);
$arrC[0] = $f;
$f = new A(wsx);
$arrC[1] = $f;
print_r($arrC);
foreach($arrC as $d) { echo (.$d-name.); }
echo \n--\n;
// works as expected
$arrD = array();
$h = new A(qaz);
$arrD[0] = $h;
$h = new A(wsx);
$arrD[1] = $h;
print_r($arrD);
foreach($arrD as $g) { echo (.$g-name.); }
echo \n--\n;
// both items in the array reference the
// second object (references $i) - this is correct
$arrE = array();
$i = new A(qaz);
$arrE[0] = $i;
$i = new A(wsx);
$arrE[1] = $i;
print_r($arrE);
foreach($arrE as $j) { echo (.$j-name.); }
echo \n--\n;
---
which gives the following output on
PHP 5.0.2 (cli) (built: Nov 9 2004 19:00:36):
A Object
(
[name] = wsx
)
A Object
(
[name] = wsx
)
Array
(
[0] = A Object
(
[name] = qaz
)
[1] = A Object
(
[name] = wsx
)
)
(qaz)(qaz)
(qaz)(qaz)
--
Array
(
[0] = A Object
(
[name] = qaz
)
[1] = A Object
(
[name] = wsx
)
)
(qaz)(wsx)
--
Array
(
[0] = A Object
(
[name] = qaz
)
[1] = A Object
(
[name] = wsx
)
)
(qaz)(wsx)
--
Array
(
[0] = A Object
(
[name] = qaz
)
[1] = A Object
(
[name] = wsx
)
)
(qaz)(wsx)
--
Array
(
[0] = A Object
(
[name] = wsx
)
[1] = A Object
(
[name] = wsx
)
)
(wsx)(wsx)
--
news.php.net wrote:
No
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?!!! I cna't believe! Sorry, if im wrong...
30 2005 16:07 news.php.net (a):
?
class A
{
var $name;
function A($str)
{
$this-name = $str;
}
}
$arr = array();
//Put to array to objects of class A,
// where their attribute A::a is assigned a different value
//objects are assigned to an array by reference
$a = new A(qaz);
$arr[0] = $a;
$a = new A(wsx);
$arr[1] = $a;
//But watch the output!!!
// It is (qaz)(qaz), which means that the attribute of a first
// object assigned to array is outputted!!! WHY?!?!!!
foreach($arr as $a)
{
echo (.$a-name.);
}
?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug?
Rory McKinley wrote: Hi Probably a trivial question While trying to use mysqli on my dev machine, PHP returns the following: Fatal error: Trying to clone an uncloneable object of class mysqli After STFW I have found a solution that involves swiching off compatibility with Zend Engine 1 in php.ini. However, after going to bugs.php.net, it seems that it has not been logged as a bug. So, the question would be - do I log it or am I wasting their time? I think they will probably disregard it, I believe that when Ze1compat mode is on the object is at some time being truely copied where under 'normal' situations (ie. using the ZE2 object model) assigning the object to another var will merely create a reference - since, apparently, creating a copy of the object is not allowed you get the error when the engine trys to clone it (when you assign the created object to another var, possibly when returning it from a function/method). Also I recommend switching off ZE1Compat mode if you don't need - it means you get all the cool stuff from PHP5 - like proper object referencing (i.e. no more worries about using ampersand to pass objs by reference etc) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug in PHP 4.3.4?
Octavian Rasnita wrote:
Hi all,
I use the following program:
function print_quotes () {
output_reset_rewrite_vars();
echo EOF
table
...
/table
EOF;
}
I have tried this program under Fedora Core 2 in command line mode and on an
Apache web server with the same results.
Do you have suggestions for making this program work and why does this
happen?
I think the problem is with your 'here document' this is the traditional
way of doing things in perl but in php you could 'go back into HTML. by
using the '?' sequence. Thus your program might become
function print_quotes () {
output_reset_rewrite_vars();
?
table
...
/table
?
}
There are pros and cons of both approach but the bit of code i have
given will produce the expected result.
--
Raditha Dissanayake.
--
http://www.radinks.com/print/card-designer/ | Card Designer Applet
http://www.radinks.com/upload/ | Drag and Drop Upload
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug in PHP 4.3.4?
Thank you. I will try that solution if it works, but the question still
remains...
Is PHP so buggy? The 'here document' should work without a problem in PHP
also.
My code works fine with PHP 5 (fortunately) under Windows, but it doesn't
work with PHP 4.3.4 under Linux.
I think I need to upgrade php under Linux also...
Teddy
- Original Message -
From: Raditha Dissanayake [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, November 29, 2004 5:29 PM
Subject: Re: [PHP] Is this a bug in PHP 4.3.4?
Octavian Rasnita wrote:
Hi all,
I use the following program:
function print_quotes () {
output_reset_rewrite_vars();
echo EOF
table
...
/table
EOF;
}
I have tried this program under Fedora Core 2 in command line mode and on
an
Apache web server with the same results.
Do you have suggestions for making this program work and why does this
happen?
I think the problem is with your 'here document' this is the traditional
way of doing things in perl but in php you could 'go back into HTML. by
using the '?' sequence. Thus your program might become
function print_quotes () {
output_reset_rewrite_vars();
?
table
...
/table
?
}
There are pros and cons of both approach but the bit of code i have
given will produce the expected result.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug in PHP 4.3.4?
On Mon, 29 Nov 2004 17:58:27 +0200, Octavian Rasnita [EMAIL PROTECTED] wrote: Is PHP so buggy? The 'here document' should work without a problem in PHP also. The latest stable PHP 4 is rock solid from where I'm sitting. We have a bunch of Debian servers running 4.3.9 with no issues. My code works fine with PHP 5 (fortunately) under Windows, but it doesn't work with PHP 4.3.4 under Linux. I think I need to upgrade php under Linux also... I would defiantly upgrade. Hundreds of bugs have been fixed from 4.3.4 - 4.3.9. http://www.php.net/ChangeLog-4.php -- Greg Donald Zend Certified Engineer http://gdconsultants.com/ http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug in PHP 4.3.4?
On Mon, 29 Nov 2004 10:28:57 -0600, Greg Donald [EMAIL PROTECTED] wrote: I would defiantly upgrade. Definitely too. :) -- Greg Donald Zend Certified Engineer http://gdconsultants.com/ http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is this a bug in PHP 4.3.4?
Octavian Rasnita wrote: Thank you. I will try that solution if it works, but the question still remains... Is PHP so buggy? The 'here document' should work without a problem in PHP also. It probably wasn't a bug in php 4.3.4 but as greg has pointed out you probably should upgrade anyway. Here documents are pretty hard to work with at the best of times and it's quite easy to make a teeny weeny hard to detect typo., My code works fine with PHP 5 (fortunately) under Windows, but it doesn't work with PHP 4.3.4 under Linux. I think I need to upgrade php under Linux also... -- Raditha Dissanayake. -- http://www.radinks.com/print/card-designer/ | Card Designer Applet http://www.radinks.com/upload/ | Drag and Drop Upload -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Sessions problem bug
On the server i use: Session.auto_start is off Session.use_cookie is on Session.use_trans_sid is 1 I do not set the session id myself All pages that requite the sessions have session_start() at the very first line -Original Message- From: Jason Barnett [mailto:[EMAIL PROTECTED] Sent: woensdag 27 oktober 2004 11:41 To: [EMAIL PROTECTED] Subject: [PHP] Re: Sessions problem bug Are you using cookie-based sessions? Thus sayeth the manual: Note: When using session cookies, specifying an id for session_id() will always send a new cookie when session_start() is called, regardless if the current session id is identical to the one being set. Thanks google. Reinhart Viane wrote: Some days ago I asked some questions concerning php and sessions Apparently it seems to be a bug: 'When you use a session name that has only numbers, each call to session_start seems to regenerate a new session id, so the session does not persist.' http://bugs.php.net/search.php?search_for=sessionboolean=0limit=10o rd er_by=direction=ASCcmd=displaystatus=Openbug_type%5B%5D=Session+rela tedphp_os=phpver=assign=author_email=bug_age=0 And there you pick bug with ID 27688 Just to let everyone know. Greetz, Reinhart Viane Reinhart Viane [EMAIL PROTECTED] Domos || D-Studio Graaf Van Egmontstraat 15/3 -- B 2800 Mechelen -- tel +32 15 44 89 01 -- fax +32 15 43 25 26 STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Dissappearing instance variables; Bug or Feature?
In PHP4 $this-one = $one; assigns a *copy* of $one to $this-one. You
need to use $this-one = $one;
The code will work as expected in PHP5 (and zend.ze1_compatibility_mode
set to off).
Ryan Briones wrote:
This is a scaled down example of something I'm doing in some code. The
results are very funky. I guess I could understand this happening if
$two was out of scope when print_r($this) was called in
One()...actually no I couldn't.
?php
Class One {
function One() {
$this-test = array();
$two = new Two( $this );
print_r( $this );
}
function set( $index, $value ) {
$this-test[$index] = $value;
}
}
Class Two {
var $one = null;
function Two( $one ) {
$this-one = $one;
$this-one-set( 'foo', 1 );
print_r($this);
}
}
$obj = new One;
?
OUTPUT:
two Object
(
[one] = one Object
(
[test] = Array
(
[foo] = 1
)
)
)
one Object
(
[test] = Array
(
)
)
This only happens if you assign the reference passed to the second
class as an instance variable. If you call the reference directly, the
variable persists. ie:
?php
Class One {
function One() {
$this-test = array();
$two = new Two( $this );
print_r( $this );
}
function set( $index, $value ) {
$this-test[$index] = $value;
}
}
Class Two {
var $one = null;
function Two( $one ) {
$one-set( 'foo', 1 );
}
}
$obj = new One;
?
OUTPUT:
one Object
(
[test] = Array
(
[foo] = 1
)
)
Any Ideas?
Ryan Briones
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [PHP5] paradox ? Bug ?
WRONG !
Read the manual about __set() and __get().
And read http://www.php.net/~helly/php/ext/spl/index.html about arrayAccess.
Php 5 allow you to overloading property dynamicaly with __set() and
__get(). And you can access an object like an array with arrayAccess
interface.
There is no nonsense in my code.
Fred.
Daniel Kullik wrote:
Hello Frédéric.
This is neither a bug nor a paradox. The code you've posted just
contains some nonsense.
$foo['bar'] = 'bar'; cannot work since $foo is an object and not an
array. And even $foo-bar = 'bar'; cannot work because there is no
property $bar.
Frédéric hardy wrote:
Hello -
I think there is a bug or a paradox in the php 5 object model
implementation.
This is an example :
?php
class foo implements arrayAccess
{
private $array = array();
function __construct() {}
function __get($key)
{
return $this-offsetGet($key);
}
function __set($key, $value)
{
$this-offsetSet($key, $value);
}
function offsetExists($key)
{
return isset($this-array[$key]);
}
function offsetGet($key)
{
return $this-array[$key];
}
function offsetSet($key, $value)
{
$this-array[$key] = $value;
}
function offsetUnset($key)
{
unset($this-array[$key];
}
}
$foo = new foo();
echo (isset($foo['bar']) == true ? 'set' : 'not set');
$foo['bar'] = 'bar';
echo (isset($foo['bar']) == true ? 'set' : 'not set');
echo $foo['bar'];
#Expected result :
# not set
# set
# bar
#Real result
# not set
# set
# bar
# !! GREAT !!
#Now, the same thing with __get() and __set()
unset($foo);
$foo = new foo();
echo (isset($foo-array) == true ? 'array is set' : 'array is not set');
echo (isset($foo-bar) == true ? 'bar is set' : 'bar is not set');
$foo-bar = 'bar';
echo (isset($foo['bar']) == true ? 'bar is set' : 'bar is not set');
echo $foo-bar;
#Expected result :
# array is set
# bar is not set
# bar is set
# bar
#Real result
# array is set # Ok !
# bar is not set # Ok !
# bar is not set # PROBLEM PROBLEM
# bar
# !! NOT GREAT !!
?
It is very strange.
isset() does not return the good value on property wich was set with
__set() !!
But isset() return the good value on property wich was set in the
class !!
And isset() return the good value on value wich was set with
offsetSet() method !!
It is a paradox !
I think that isset MUST return the same value in all case.
What do you think of ?
Fred.
Warning : the php code may be wrong (parse error...), i can not
validate it in php5 currently
--
===
Frederic HARDYEmail: [EMAIL PROTECTED]
HEXANET SARL URL: http://www.hexanet.fr/
ZAC Les CharmillesTel: +33 (0)3 26 79 30 05
3, allée Thierry Sabine Direct: +33 (0)3 26 61 77 84
BP 202 - 51686 REIMS CEDEX 2 FRANCE
===
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [PHP5] paradox ? Bug ?
Moreover, $foo['bar'] = 'bar' work perfectly...
Fred.
Frédéric Hardy wrote:
WRONG !
Read the manual about __set() and __get().
And read http://www.php.net/~helly/php/ext/spl/index.html about
arrayAccess.
Php 5 allow you to overloading property dynamicaly with __set() and
__get(). And you can access an object like an array with arrayAccess
interface.
There is no nonsense in my code.
Fred.
Daniel Kullik wrote:
Hello Frédéric.
This is neither a bug nor a paradox. The code you've posted just
contains some nonsense.
$foo['bar'] = 'bar'; cannot work since $foo is an object and not an
array. And even $foo-bar = 'bar'; cannot work because there is no
property $bar.
Frédéric hardy wrote:
Hello -
I think there is a bug or a paradox in the php 5 object model
implementation.
This is an example :
?php
class foo implements arrayAccess
{
private $array = array();
function __construct() {}
function __get($key)
{
return $this-offsetGet($key);
}
function __set($key, $value)
{
$this-offsetSet($key, $value);
}
function offsetExists($key)
{
return isset($this-array[$key]);
}
function offsetGet($key)
{
return $this-array[$key];
}
function offsetSet($key, $value)
{
$this-array[$key] = $value;
}
function offsetUnset($key)
{
unset($this-array[$key];
}
}
$foo = new foo();
echo (isset($foo['bar']) == true ? 'set' : 'not set');
$foo['bar'] = 'bar';
echo (isset($foo['bar']) == true ? 'set' : 'not set');
echo $foo['bar'];
#Expected result :
# not set
# set
# bar
#Real result
# not set
# set
# bar
# !! GREAT !!
#Now, the same thing with __get() and __set()
unset($foo);
$foo = new foo();
echo (isset($foo-array) == true ? 'array is set' : 'array is not set');
echo (isset($foo-bar) == true ? 'bar is set' : 'bar is not set');
$foo-bar = 'bar';
echo (isset($foo['bar']) == true ? 'bar is set' : 'bar is not set');
echo $foo-bar;
#Expected result :
# array is set
# bar is not set
# bar is set
# bar
#Real result
# array is set # Ok !
# bar is not set # Ok !
# bar is not set # PROBLEM PROBLEM
# bar
# !! NOT GREAT !!
?
It is very strange.
isset() does not return the good value on property wich was set with
__set() !!
But isset() return the good value on property wich was set in the
class !!
And isset() return the good value on value wich was set with
offsetSet() method !!
It is a paradox !
I think that isset MUST return the same value in all case.
What do you think of ?
Fred.
Warning : the php code may be wrong (parse error...), i can not
validate it in php5 currently
--
===
Frederic HARDYEmail: [EMAIL PROTECTED]
HEXANET SARL URL: http://www.hexanet.fr/
ZAC Les CharmillesTel: +33 (0)3 26 79 30 05
3, allée Thierry Sabine Direct: +33 (0)3 26 61 77 84
BP 202 - 51686 REIMS CEDEX 2 FRANCE
===
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [PHP5] paradox ? Bug ?
Well alright, then I ought to read the suggested sources. Thanks for the
advice.
Anyway, doesn't it cause trouble to have $array as a private member?
Frédéric hardy wrote:
Moreover, $foo['bar'] = 'bar' work perfectly...
Fred.
Frédéric Hardy wrote:
WRONG !
Read the manual about __set() and __get().
And read http://www.php.net/~helly/php/ext/spl/index.html about
arrayAccess.
Php 5 allow you to overloading property dynamicaly with __set() and
__get(). And you can access an object like an array with arrayAccess
interface.
There is no nonsense in my code.
Fred.
Daniel Kullik wrote:
Hello Frédéric.
This is neither a bug nor a paradox. The code you've posted just
contains some nonsense.
$foo['bar'] = 'bar'; cannot work since $foo is an object and not an
array. And even $foo-bar = 'bar'; cannot work because there is no
property $bar.
Frédéric hardy wrote:
Hello -
I think there is a bug or a paradox in the php 5 object model
implementation.
This is an example :
?php
class foo implements arrayAccess
{
private $array = array();
function __construct() {}
function __get($key)
{
return $this-offsetGet($key);
}
function __set($key, $value)
{
$this-offsetSet($key, $value);
}
function offsetExists($key)
{
return isset($this-array[$key]);
}
function offsetGet($key)
{
return $this-array[$key];
}
function offsetSet($key, $value)
{
$this-array[$key] = $value;
}
function offsetUnset($key)
{
unset($this-array[$key];
}
}
$foo = new foo();
echo (isset($foo['bar']) == true ? 'set' : 'not set');
$foo['bar'] = 'bar';
echo (isset($foo['bar']) == true ? 'set' : 'not set');
echo $foo['bar'];
#Expected result :
# not set
# set
# bar
#Real result
# not set
# set
# bar
# !! GREAT !!
#Now, the same thing with __get() and __set()
unset($foo);
$foo = new foo();
echo (isset($foo-array) == true ? 'array is set' : 'array is not
set');
echo (isset($foo-bar) == true ? 'bar is set' : 'bar is not set');
$foo-bar = 'bar';
echo (isset($foo['bar']) == true ? 'bar is set' : 'bar is not set');
echo $foo-bar;
#Expected result :
# array is set
# bar is not set
# bar is set
# bar
#Real result
# array is set # Ok !
# bar is not set # Ok !
# bar is not set # PROBLEM PROBLEM
# bar
# !! NOT GREAT !!
?
It is very strange.
isset() does not return the good value on property wich was set with
__set() !!
But isset() return the good value on property wich was set in the
class !!
And isset() return the good value on value wich was set with
offsetSet() method !!
It is a paradox !
I think that isset MUST return the same value in all case.
What do you think of ?
Fred.
Warning : the php code may be wrong (parse error...), i can not
validate it in php5 currently
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP has a bug...?
From: Stephen Craton [EMAIL PROTECTED] I was making a parabola grapher and I was testing out some values. Part of the script is to take the variable b and multiply it was negative one, then multiply by 2 times a. I entered a test value where a equals 1, b equals 0, and c equals 0. The result told me that -1 times 0 is -0. Here's the code I'm using: $x = (-1 * $b) / (2 * $a); What version of PHP and what OS? I don't see this replicated on 4.3.3/Win2k. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Possible Leap Year bug with strtotime (4.3.4)?
I don't think it's so much a bug as it is just some odd behavior. If you
use 'this monday' the results are correct.
$start = strtotime('this monday');
Keith
At 02:44 PM 2/28/2004, Rob Petty wrote:
I am getting incorrect results from strtotime:
[dali]$ uname -a
Linux dali 2.4.24-grsec+w+fhs5+gr1913+nfs+++p3+c3+bu+gr0b-v6.182 #1 SMP
Mon Jan 5 12:43:44 PST 2004 i686 unknown
[dali]$ date
Sat Feb 28 14:33:39 PST 2004
[dali]$ cat t1.php
?
$start = strtotime('next monday');
echo ('Start timestamp: '.$start.'br'.\n);
echo ('Next Monday: '.date('l, M d Y',$start).'br'.\n);
$first = strtotime('first Monday',$start);
echo ('First Monday: '.date('l, M d Y',$first).'br'.\n);
$oneth = strtotime('1 Monday',$start);
echo ('1 Monday: '.date('l, M d Y',$oneth).'br'.\n);
$next = strtotime('next Monday',$start);
echo ('Next Monday: '.date('l, M d Y',$next).'br'.\n);
$twoth = strtotime('2 Monday',$start);
echo ('2 Monday: '.date('l, M d Y',$twoth).'br'.\n);
$third = strtotime('third Monday',$start);
echo ('Third Monday: '.date('l, M d Y',$third).'br'.\n);
$threeth = strtotime('3 Monday',$start);
echo ('3 Monday: '.date('l, M d Y',$threeth).'br'.\n);
?
[dali]$ php t1.php
Content-type: text/html
X-Powered-By: PHP/4.3.4
Start timestamp: 1078732800br
Next Monday: Monday, Mar 08 2004br
First Monday: Monday, Mar 08 2004br
1 Monday: Monday, Mar 08 2004br
Next Monday: Monday, Mar 15 2004br
2 Monday: Monday, Mar 15 2004br
Third Monday: Monday, Mar 22 2004br
3 Monday: Monday, Mar 22 2004br
[dali]$
next monday should be Mar 01 2004 instead of Mar 08 2004. Any ideas?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: weird header() (bug may be)
On Thursday 12 February 2004 14:40, Eric Bolikowski wrote: Headers have to be pretty accurate, or it will cause trouble. And your redirect header is not quite correct. It should be this: header(Location: another_page.php); and NOT header(Location:another_page.php); What you need here is a space between Location: and the URL. Also it should be an absolute URL otherwise it might break on some (standards compliant only) browsers: header(Location: http://www.example.tld/another_page.php;); -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* Honesty is the best policy, but insanity is a better defense. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] IS THIS A BUG?
* Thus wrote Steve Todd ([EMAIL PROTECTED]): Is it possible to define a variable, such as: $foo = bar; and then do as follows to create a totally different variable: $$foo = text here; this seems to mean $bar = text here;. Is this a bug or can we legally use it. perfectly legal, its called a variable variable... http://php.net/variables.variable Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] IS THIS A BUG?
Steve Todd wrote: Is it possible to define a variable, such as: $foo = bar; and then do as follows to create a totally different variable: $$foo = text here; this seems to mean $bar = text here;. Is this a bug or can we legally use it. Yes it's legal. http://us2.php.net/manual/en/language.variables.variable.php -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] IS THIS A BUG?
--- Steve Todd [EMAIL PROTECTED] wrote: Is it possible to define a variable, such as: $foo = bar; and then do as follows to create a totally different variable: $$foo = text here; this seems to mean $bar = text here;. Is this a bug or can we legally use it. It is not a bug, but it's still PHP: http://bbspot.com/News/2000/6/php_suspend.html Chris = Become a better Web developer with the HTTP Developer's Handbook http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] IS THIS A BUG?
Steve Todd mailto:[EMAIL PROTECTED] on Wednesday, August 27, 2003 1:28 PM said: Is this a bug or can we legally use it. It's legal. And here is an article that explains it: http://www.phphideout.com/articleview.php/5 (read near the bottom) Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] IS THIS A BUG?
No its not a bug basically what you did was assign a value to a value of a variable a $$ is how you access the value of a variable as a variable - Original Message - From: Steve Todd [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 1:27 PM Subject: [PHP] IS THIS A BUG? Is it possible to define a variable, such as: $foo = bar; and then do as follows to create a totally different variable: $$foo = text here; this seems to mean $bar = text here;. Is this a bug or can we legally use it. Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] IS THIS A BUG?
Steve Todd wrote: Is this a bug or can we legally use it. Please RTFM before posting! http://php.net/variables.variable -- The above message is encrypted with double rot13 encoding. Any unauthorized attempt to decrypt it will be prosecuted to the full extent of the law. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: header headers_sent BUG
read www.php.net/variables.scope Eric Fleming wrote: I am having some problems using variables in included files. Can someone please look at my code below and see how I might accomplish what I am trying to do? ?php $subnav = home; include(incHeader.php); ? !--- CONTENT AREA --- The content would go here. !--- END CONTENT AREA --- ?php include (incFooter.php); ? Now, when I try to reference the subnav variable in the inHeader.php or incFooter.php files, it comes up blank. I am basically trying to adjust the navigation on each page depending on the page I am on. I am just learning PHP, have programmed in ColdFusion for years and in ColdFusion this was not a problem. Any ideas? Eric Fleming -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 4.3.3-RC1 = possible bug in in_array()?
in_array searches for a value, you suply key. This will work as you expect:
$data = array();
foreach ($this-_array_a as $key = $value) {
if (! in_array($value, $this-_array_b)
$data['added'][$key] = $this-_array_a[$key];
}
Branko F. Grac(nar wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
I've just found weird thing about in_array() function.
Platform: FreeBSD 5.1/PHP 4.3.3-RC1
Consider this code:
$this-_array_a and $this-_array_b ARE IDENTICAL
$data = array();
foreach ($this-_array_a as $key = $value) {
if (! in_array($key, $this-_array_b)
$data['added'][$key] = $this-_array_a[$key];
}
Therefore after execution $data should be empty.
But there is whole $this-_array_a in $data after execution...
The following code works ($data is empty after execution):
foreach ($this-_array_a as $key = $value) {
if (! isset($this-_array_b[$key]))
$data['added'][$key] = $this-_array_a[$key];
}
Why is this happening?
Brane
-BEGIN PGP SIGNATURE-
iD8DBQE/ISOGfiC/E+t8hPcRAll7AJ9EbH6FwwJC/vjsBNG3qMWvWVdmbQCggILs
UvLwPdDkKk2UrXxpPo6vF5M=
=OqAg
-END PGP SIGNATURE-
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 4.3.3-RC1 = possible bug in in_array()?
[EMAIL PROTECTED] Marek Kilimajer: in_array searches for a value, you suply key. This will work as you expect: array_key_exists searches for a key. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: header headers_sent BUG
according to the php doc, online the headers are not affected by the Output Buffer, so any functions that manipulate the OB should have no effect. flush I do not beleive will fix this issue. (* I have tested it and it did not *) Still need a good way to accomplish this. Thanks, James Ivo Fokkema wrote: You might want to check whether or not your header output is getting buffered. My suggestion is a flush() after the fist call. I'm not an expert on this, it's just an idea. HTH -- Ivo Fokkema PHP MySQL programmer Leiden University Medical Centre Netherlands James M. Luedke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello all: I am having a hard time with a small piece of code. I was wondering if someone may be able to explain why the following code will not work... I have been scratching my head for a few hours now and I am stumped. ?php header(Location: http://someplace.com;); if( ! headers_sent()) header(Location: http://somplaceelse.com;); ? So I would expect this piece of code to direct me to somplace.com. However it does not, and I always end up at somplaceelse.com. I have done a tcpdump to assist with debugging here is the output below. From the look of it the first header is getting ignored all toghether. Is there some way to force changes I made to the headers, that will make headers_sent return TRUE? Thanks, -James --- GET /tracking/test.php HTTP/1.1 Host: dev.www.someplace.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q= 0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive Cookie: toolkitAccess=1 HTTP/1.1 302 Found Date: Wed, 23 Jul 2003 10:04:55 GMT Server: Apache/1.3.27 (Unix) mod_ssl/2.8.14 OpenSSL/0.9.6d PHP/4.3.1 mod_perl/1.27 X-Powered-By: PHP/4.3.1 Location: http://someplaceelse.com Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] IsSet() and $_SESSION - BUG?
Hello everyone. I was able to determine what was causing my problem
with session variables not being persitant across page requests. I want
to give you the full scope here, so I'm going to paste the code (and if
you have any code tips, please let me know).
I think the problem might be this (and I don't know why it should be,
but maybe you can help):
If you look at file2.php, you will see that ValidAdminLogin() contains
the global $_SESSION; declaration., but that's not the problem.
ValidAdminLogin() calls a function ResetSessionVariables(), which also
contains global $_SESSION;. When global $_SESSION; is present in
ResetSessionVariables(), it seems as though the $_SESSION variables are
not being preserved across page requests (notice that
ResetSessionVariables() is called BEFORE the variables are set with the
real data, but it's really $_SESSION['uid'] we are concerned with.)
When I remove global $_SESSION; from ResetSessionVariables(), all
works fine across page request. Also note that $_SESSION['uid'] is set
when we return from the file2.php function calls as noted in the echo
command. So, why would a double global definintion negate $_SESSION?
file1.php -
?php
session_start();
include include/DatabaseConnect.php;
include include/commonphp.php;
DisableClientCaching();
if (!isset($_SESSION['uid'])) {
if ( !ValidAdminLogin($_POST['adminid'],$_POST['adminpass'])){
forceadminlogin(); }
} elseif ( !ValidAdminSession() ){
// Not a valid admin session - redirect
forceadminlogin();
}
?
html
body
?php
//We always get a value for this, but it get lost when we leave the page.
echo $_SESSION['uid'];
?
brbrbrbr
center
a href='additem.php'Add Item/a
/center
/body
/html
--- file2.php --
?php
include configvars.php;
function ValidAdminSession(){
global $_SESSION;
if ( isset($_SESSION['adminlogin']) ){ return 1; }
else { return 0;}
}
function DisableClientCaching(){
header(Expires: . gmdate(D, d M Y H:i:s) . GMT); //
Expire now
header(Last-Modified: . gmdate(D, d M Y H:i:s) . GMT); //
always modified
header(Cache-Control: no-store, no-cache, must-revalidate); //
HTTP/1.1
header(Cache-Control: post-check=0, pre-check=0, false);//
HTTP/1.0
header(Pragma: no-cache); // HTTP/1.0
}
function ResetSessionVariables(){
// WHEN I REMOVE THIS LINE, EVERYTHING WORKS FINE
// global $_SESSION;
$_SESSION['uid'] = session_id();
$_SESSION['username'] = '';
$_SESSION['adminlogin'] = False;
$_SESSION['fname'] = '';
$_SESSION['lname'] = '';
$_SESSION['email'] = '';
$_SESSION['errormesg'] = '';
}
function ValidAdminLogin($user, $pass){
global $_SESSION;
include DatabaseConnect.php;
mysql_connect($DBAddress,$DBUser,$DBPassword);
@mysql_select_db($DBDatabase) or die(ERROR);
$query=SELECT * FROM adminuser WHERE user=' . $user .' AND
pass=' . md5($pass) . ';
$results = mysql_query($query);
$num = mysql_numrows($results);
if ($num != 1){
$returnvar = false; // Make sure the user exist, and is only
one (even though it's a unique SQL field)
} else {
ResetSessionVariables();
$_SESSION['username'] = strtolower(formatformdata($user));
$_SESSION['adminlogin'] = True;
$_SESSION['fname'] = mysql_result($results,0,fname);
$_SESSION['lname'] = mysql_result($results,0,lname);
$_SESSION['email'] = mysql_result($results,0,email);
$_SESSION['uid'] = session_id();
$returnvar = true;
}
return $returnvar;
mysql_close();
}
function forceadminlogin(){
ResetSessionVariables();
header(Location: AdminLogin.php);
}
function formatformdata($mystring){
return addslashes(rawurldecode(chop($mystring)));
}
?
John Manko wrote:
I'm having a problem with the value that isset returns on $_SESSION
variables. For some reason, even if $_SESSION['uid'] is set, isset
returns FALSE. Here is the code:
-- file1.php ---
include file2.php;
if (!isset($_SESSION[uid])) {
// This first time $_SESSION[uid] is check, we should
// end up in here. However, ValidAdminLogin (next test)
// will set $_SESSION[uid] so next time we will not
// get here.
if ( !ValidAdminLogin($_POST[adminid],$_POST[adminpass]))
forceadminlogin();
} elseif ( !ValidAdminSession() )
forceadminlogin();
// this is done to show that $_SESSION[uid] is being set
// but isset still returns false
echo $_SESSION[uid];
-- file2.php ---
function ValidAdminLogin($user, $pass){
global $_SESSION;
if (The_MYSQL_Stuff_Is_NOT_OK) return false;
else
{
session_start();
$_SESSION[logged] = true;
$_SESSION[username] = $user;
$_SESSION[adminlogin] = true;
$_SESSION[fname] = $fname;
Re: [PHP] IsSet() and $_SESSION - BUG?
On Tuesday 01 July 2003 12:46, John Manko wrote: Hello everyone. I was able to determine what was causing my problem with session variables not being persitant across page requests. I want to give you the full scope here, so I'm going to paste the code (and if you have any code tips, please let me know). I think the problem might be this (and I don't know why it should be, but maybe you can help): If you look at file2.php, you will see that ValidAdminLogin() contains the global $_SESSION; declaration., but that's not the problem. ValidAdminLogin() calls a function ResetSessionVariables(), which also contains global $_SESSION;. When global $_SESSION; is present in ResetSessionVariables(), it seems as though the $_SESSION variables are not being preserved across page requests (notice that ResetSessionVariables() is called BEFORE the variables are set with the real data, but it's really $_SESSION['uid'] we are concerned with.) When I remove global $_SESSION; from ResetSessionVariables(), all works fine across page request. Also note that $_SESSION['uid'] is set when we return from the file2.php function calls as noted in the echo command. So, why would a double global definintion negate $_SESSION? I've not looked at your code but the fact is that global $_SESSION; is completely unnecessary. $_SESSION is a 'superglobal' that is available in all scopes. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* Marxist Law of Distribution of Wealth: Shortages will be divided equally among the peasants. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Found a bug in 4.2.3 re: TD and echo vs. ?php? [solved]
HH! Now that makes perfect sense.
Thank you Rasmus for that indepth reply and also the , vs . trick
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 10:11 PM
To: Daevid Vincent
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP] Re: Found a bug in 4.2.3 re: TD and echo
vs. ?php?
You are getting completely mixed up. Simplifying your example:
function foo() { echo foo; }
$a = TD.foo()./TD;
Will you agree that this is bogus code? foo() is not going to return
anything, so the resulting value of $a is going to be TD/TD.
Correct? But while that assignment is happening the foo()
function echoes
something, so you will see foo in the output, but it has
nothing to do
with what ends up in $a. Nothing changes when you change the
code to be:
function foo() { echo foo; }
echo TD.foo()./TD;
The parser is going to build a string to be echoed since you used the
string concatenation operator (dot). While building that
string one of
the components happen to output something, so that something will get
output. Then the string that was built will be output. So
what you see
is:
fooTD/TD
Perhaps it is clearer if we make the function return something:
function foo() { echo foo; return bar; }
echo TD.foo()./TD;
What do you think the output will be here? We build a string
out of the
components, but while building, foo() happens to echo foo, then we
finish constructing the string and output the final string.
So the result
is:
fooTDbar/TD
As someone else pointed out, if you use commas here, things
change a bit:
function foo() { echo foo; }
echo TD,foo(),/TD;
The comma syntax for echo is basically a shortcut for executing echo
multiple times. The above is equivalent to writing:
echo TD;
echo foo();
echo /TD;
In this case things will be output in the correct order as we are no
concatenating a bunch of parts to make a single string before
echoing it
in this case.
-Rasmus
On Fri, 4 Apr 2003, Daevid Vincent wrote:
Mmm. I'm still not following and not completely convinced.
Changing echo alarmLightYMD(); to simply
alarmLightYMD(); in the bottom
function doesn't print anything in the table cell at all
(for the first test
case).
While your idea at first makes sense and does seem like a
newbie mistake
(and you are correct, I do have nested echo statements
come to think of
it). What I don't get is why it's not consistent.
Expanding the relevant
lines, it should be like this:
echo TD.(echo IMG SRC='images/light_red.gif')./TD;
Which fails, and the other line would be (which works):
TD?php echo (echo IMG SRC='images/light_red.gif'); ?/TD
In my book, they're both double echoing the output if you
will... Are you
with me on that?
So again, why does the second one work and the first one doesn't?
-Original Message-
From: Philip Hallstrom [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 5:20 PM
To: Daevid Vincent
Cc: [EMAIL PROTECTED]
Subject: [PHP] Re: Found a bug in 4.2.3 re: TD and echo
vs. ?php?
It's a coding error... at least I think so.
change alarmLightMySQL just return the results not echo
them... echoing
them doesn't make much sense inside another echo statement...
On Fri, 4 Apr 2003, Daevid Vincent wrote:
Here, try this bullshit...
I can't upgrade to a more recent version as I'm not in
control of the
server, but I've tried it with both 4.1.2 and 4.2.3 on
linux with a RH
install. Can anyone confirm or dispute this bug exists in
later versions?
How does a parsing error like this go un-noticed for so long?
Obviously I took out all the interesting stuff in the page
and so that can't
be blamed. This is about as bare skeleton test case as
you can get.
*sigh*
snip
?php
function alarmLightYMD()
{
return IMG SRC='images/light_red.gif';
}
function alarmLightMySQL()
{
echo alarmLightYMD();
}
?
html
head
titleFUCKED UP PHP Bug #1234170238741023/title
/head
body
PHP Version 4.1.2BR
PHP Version 4.2.3BR
BR
Why the FUCK doesn't this work
P
TABLE BORDER=1
?php
for ($i = 0; $i 10; $i++ ) {
echo TR;
echo TD.alarmLightMySQL()./TD;
echo TDthis fails!/TD;
echo /TR;
}
?
/TABLE
HR
YET THIS DOES!
P
TABLE BORDER=1
?php for ($i = 0; $i 10; $i++ ) { ?
TR
TD?php echo alarmLightMySQL(); ?/TD
TDthis works/TD
/TR
?php
RE: [PHP] Re: Found a bug in 4.2.3 re: TD and echo vs. ?php?
Mmm. I'm still not following and not completely convinced.
Changing echo alarmLightYMD(); to simply alarmLightYMD(); in the bottom
function doesn't print anything in the table cell at all (for the first test
case).
While your idea at first makes sense and does seem like a newbie mistake
(and you are correct, I do have nested echo statements come to think of
it). What I don't get is why it's not consistent. Expanding the relevant
lines, it should be like this:
echo TD.(echo IMG SRC='images/light_red.gif')./TD;
Which fails, and the other line would be (which works):
TD?php echo (echo IMG SRC='images/light_red.gif'); ?/TD
In my book, they're both double echoing the output if you will... Are you
with me on that?
So again, why does the second one work and the first one doesn't?
-Original Message-
From: Philip Hallstrom [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 5:20 PM
To: Daevid Vincent
Cc: [EMAIL PROTECTED]
Subject: [PHP] Re: Found a bug in 4.2.3 re: TD and echo vs. ?php?
It's a coding error... at least I think so.
change alarmLightMySQL just return the results not echo
them... echoing
them doesn't make much sense inside another echo statement...
On Fri, 4 Apr 2003, Daevid Vincent wrote:
Here, try this bullshit...
I can't upgrade to a more recent version as I'm not in
control of the
server, but I've tried it with both 4.1.2 and 4.2.3 on
linux with a RH
install. Can anyone confirm or dispute this bug exists in
later versions?
How does a parsing error like this go un-noticed for so long?
Obviously I took out all the interesting stuff in the page
and so that can't
be blamed. This is about as bare skeleton test case as you can get.
*sigh*
snip
?php
function alarmLightYMD()
{
return IMG SRC='images/light_red.gif';
}
function alarmLightMySQL()
{
echo alarmLightYMD();
}
?
html
head
titleFUCKED UP PHP Bug #1234170238741023/title
/head
body
PHP Version 4.1.2BR
PHP Version 4.2.3BR
BR
Why the FUCK doesn't this work
P
TABLE BORDER=1
?php
for ($i = 0; $i 10; $i++ ) {
echo TR;
echo TD.alarmLightMySQL()./TD;
echo TDthis fails!/TD;
echo /TR;
}
?
/TABLE
HR
YET THIS DOES!
P
TABLE BORDER=1
?php for ($i = 0; $i 10; $i++ ) { ?
TR
TD?php echo alarmLightMySQL(); ?/TD
TDthis works/TD
/TR
?php } ?
/TABLE
/body
/html
snip
Ezekiel 25:17. The path of the righteous man is beset on
all sides by the
inequities of the selfish and the tyranny of evil men.
Blessed is he who in
the name of charity and goodwill shepherds the weak through
the valley of
darkness, for he is TRULY his brother's keeper and the
finder of lost
children. And I will strike down upon thee with GREAT vengeance and
FU-U-U-URIOUS anger, those who attempt to poison, and
destroy my brothers!
And you will KNOW my name is the Lord, when I lay my
vengeance upon thee!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Found a bug in 4.2.3 re: TD and echo vs. ?php?
Neither works. You're doing something like this in your other code:
function foo(){
echo foo;
}
echo foo();
The foo() doesn't return the (non-existant) value from echo, it simply
echo()s and returns nothing, and there's nothing wrong with echo()ing
nothing. It would fail if you were using
function foo(){
return echo foo;
}
echo foo();
Daevid Vincent wrote:
Mmm. I'm still not following and not completely convinced.
Changing echo alarmLightYMD(); to simply alarmLightYMD(); in the bottom
function doesn't print anything in the table cell at all (for the first test
case).
While your idea at first makes sense and does seem like a newbie mistake
(and you are correct, I do have nested echo statements come to think of
it). What I don't get is why it's not consistent. Expanding the relevant
lines, it should be like this:
echo TD.(echo IMG SRC='images/light_red.gif')./TD;
Which fails, and the other line would be (which works):
TD?php echo (echo IMG SRC='images/light_red.gif'); ?/TD
In my book, they're both double echoing the output if you will... Are you
with me on that?
So again, why does the second one work and the first one doesn't?
-Original Message-
From: Philip Hallstrom [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 5:20 PM
To: Daevid Vincent
Cc: [EMAIL PROTECTED]
Subject: [PHP] Re: Found a bug in 4.2.3 re: TD and echo vs. ?php?
It's a coding error... at least I think so.
change alarmLightMySQL just return the results not echo
them... echoing
them doesn't make much sense inside another echo statement...
On Fri, 4 Apr 2003, Daevid Vincent wrote:
Here, try this bullshit...
I can't upgrade to a more recent version as I'm not in
control of the
server, but I've tried it with both 4.1.2 and 4.2.3 on
linux with a RH
install. Can anyone confirm or dispute this bug exists in
later versions?
How does a parsing error like this go un-noticed for so long?
Obviously I took out all the interesting stuff in the page
and so that can't
be blamed. This is about as bare skeleton test case as you can get.
*sigh*
snip
?php
function alarmLightYMD()
{
return IMG SRC='images/light_red.gif';
}
function alarmLightMySQL()
{
echo alarmLightYMD();
}
?
html
head
titleFUCKED UP PHP Bug #1234170238741023/title
/head
body
PHP Version 4.1.2BR
PHP Version 4.2.3BR
BR
Why the FUCK doesn't this work
P
TABLE BORDER=1
?php
for ($i = 0; $i 10; $i++ ) {
echo TR;
echo TD.alarmLightMySQL()./TD;
echo TDthis fails!/TD;
echo /TR;
}
?
/TABLE
HR
YET THIS DOES!
P
TABLE BORDER=1
?php for ($i = 0; $i 10; $i++ ) { ?
TR
TD?php echo alarmLightMySQL(); ?/TD
TDthis works/TD
/TR
?php } ?
/TABLE
/body
/html
snip
Ezekiel 25:17. The path of the righteous man is beset on
all sides by the
inequities of the selfish and the tyranny of evil men.
Blessed is he who in
the name of charity and goodwill shepherds the weak through
the valley of
darkness, for he is TRULY his brother's keeper and the
finder of lost
children. And I will strike down upon thee with GREAT vengeance and
FU-U-U-URIOUS anger, those who attempt to poison, and
destroy my brothers!
And you will KNOW my name is the Lord, when I lay my
vengeance upon thee!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
The above message is encrypted with double rot13 encoding. Any unauthorized attempt
to decrypt it will be prosecuted to the full extent of the law.
RE: [PHP] Re: Found a bug in 4.2.3 re: TD and echo vs. ?php?
You are getting completely mixed up. Simplifying your example:
function foo() { echo foo; }
$a = TD.foo()./TD;
Will you agree that this is bogus code? foo() is not going to return
anything, so the resulting value of $a is going to be TD/TD.
Correct? But while that assignment is happening the foo() function echoes
something, so you will see foo in the output, but it has nothing to do
with what ends up in $a. Nothing changes when you change the code to be:
function foo() { echo foo; }
echo TD.foo()./TD;
The parser is going to build a string to be echoed since you used the
string concatenation operator (dot). While building that string one of
the components happen to output something, so that something will get
output. Then the string that was built will be output. So what you see
is:
fooTD/TD
Perhaps it is clearer if we make the function return something:
function foo() { echo foo; return bar; }
echo TD.foo()./TD;
What do you think the output will be here? We build a string out of the
components, but while building, foo() happens to echo foo, then we
finish constructing the string and output the final string. So the result
is:
fooTDbar/TD
As someone else pointed out, if you use commas here, things change a bit:
function foo() { echo foo; }
echo TD,foo(),/TD;
The comma syntax for echo is basically a shortcut for executing echo
multiple times. The above is equivalent to writing:
echo TD;
echo foo();
echo /TD;
In this case things will be output in the correct order as we are no
concatenating a bunch of parts to make a single string before echoing it
in this case.
-Rasmus
On Fri, 4 Apr 2003, Daevid Vincent wrote:
Mmm. I'm still not following and not completely convinced.
Changing echo alarmLightYMD(); to simply alarmLightYMD(); in the bottom
function doesn't print anything in the table cell at all (for the first test
case).
While your idea at first makes sense and does seem like a newbie mistake
(and you are correct, I do have nested echo statements come to think of
it). What I don't get is why it's not consistent. Expanding the relevant
lines, it should be like this:
echo TD.(echo IMG SRC='images/light_red.gif')./TD;
Which fails, and the other line would be (which works):
TD?php echo (echo IMG SRC='images/light_red.gif'); ?/TD
In my book, they're both double echoing the output if you will... Are you
with me on that?
So again, why does the second one work and the first one doesn't?
-Original Message-
From: Philip Hallstrom [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2003 5:20 PM
To: Daevid Vincent
Cc: [EMAIL PROTECTED]
Subject: [PHP] Re: Found a bug in 4.2.3 re: TD and echo vs. ?php?
It's a coding error... at least I think so.
change alarmLightMySQL just return the results not echo
them... echoing
them doesn't make much sense inside another echo statement...
On Fri, 4 Apr 2003, Daevid Vincent wrote:
Here, try this bullshit...
I can't upgrade to a more recent version as I'm not in
control of the
server, but I've tried it with both 4.1.2 and 4.2.3 on
linux with a RH
install. Can anyone confirm or dispute this bug exists in
later versions?
How does a parsing error like this go un-noticed for so long?
Obviously I took out all the interesting stuff in the page
and so that can't
be blamed. This is about as bare skeleton test case as you can get.
*sigh*
snip
?php
function alarmLightYMD()
{
return IMG SRC='images/light_red.gif';
}
function alarmLightMySQL()
{
echo alarmLightYMD();
}
?
html
head
titleFUCKED UP PHP Bug #1234170238741023/title
/head
body
PHP Version 4.1.2BR
PHP Version 4.2.3BR
BR
Why the FUCK doesn't this work
P
TABLE BORDER=1
?php
for ($i = 0; $i 10; $i++ ) {
echo TR;
echo TD.alarmLightMySQL()./TD;
echo TDthis fails!/TD;
echo /TR;
}
?
/TABLE
HR
YET THIS DOES!
P
TABLE BORDER=1
?php for ($i = 0; $i 10; $i++ ) { ?
TR
TD?php echo alarmLightMySQL(); ?/TD
TDthis works/TD
/TR
?php } ?
/TABLE
/body
/html
snip
Ezekiel 25:17. The path of the righteous man is beset on
all sides by the
inequities of the selfish and the tyranny of evil men.
Blessed is he who in
the name of charity and goodwill shepherds the weak through
the valley of
darkness, for he is TRULY his brother's keeper and the
finder of lost
children. And I will strike down upon thee with GREAT vengeance and
FU-U-U-URIOUS anger, those who attempt to poison, and
destroy my brothers!
And you will KNOW my name is the Lord, when I lay my
vengeance upon thee!
--
PHP
Re: [PHP] Is there a bug in fopen() - solved, maybe
At 08:33 30.01.2003, zlu tarch said: [snip] I was not able to either telnet (via port 80), or connect using fopen() to www2.barchart.com. But it seems that it is fine now. Perhaps it was a temp problem on the site's server, but still, I had no problems connecting to the site via a browser while fopen and telnet were not working. It would be interesting to see if anyone else experienced similar problems. [snip] Possibly the server is behind a firewall and is not allowed to make an outgoing connection on the specific port? -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
So sprach 1LT John W. Holmes am 2003-01-27 um 15:49:33 -0500 :
Actually, 08 is equal to 8 in PHP. PHP will convert the string to an
No, that's not true:
if (08 == 8){ echo equal; }
if (08 === 8){ echo more equal; }
This will only print equal and not more equal.
Alexander Skwar
--
How to quote: http://learn.to/quote (german) http://quote.6x.to (english)
Homepage: http://www.iso-top.biz |Jabber: [EMAIL PROTECTED]
iso-top.biz - Die günstige Art an Linux Distributionen zu kommen
Uptime: 1 day 15 hours 46 minutes
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
--- Alexander Skwar [EMAIL PROTECTED] wrote:
So sprach 1LT John W. Holmes am 2003-01-27 um 15:49:33
-0500 :
Actually, 08 is equal to 8 in PHP. PHP will convert
the string to an
No, that's not true:
if (08 == 8){ echo equal; }
if (08 === 8){ echo more equal; }
This will only print equal and not more equal.
Good thing he didn't say they were more equal, right?
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Is there a bug in fopen() - solved, maybe
I was not able to either telnet (via port 80), or connect using fopen() to www2.barchart.com. But it seems that it is fine now. Perhaps it was a temp problem on the site's server, but still, I had no problems connecting to the site via a browser while fopen and telnet were not working. It would be interesting to see if anyone else experienced similar problems. --- Evan Nemerson [EMAIL PROTECTED] wrote: Perhaps you could post the pertinant code, so we can determine why it doesn't work... On Wednesday 29 January 2003 10:29 pm, zlu tarch wrote: Hi, I think fopen() and fsockopen() have a bug. For example, while I had no problem connecting to http://www2.barchart.com; using a browser, it was not possible to open a socket connection uisng either fopen() or fsockopen() (i.e., none could initilize the socket). I was wondering if anyone else had similar problems. Please let me know if there is a bug, or I was doing something wrong. Thanks, Zlutarch P.S., both fopen() and fsockopen() can be used to connect to www.barchart.com, but NOT www2.barchart.com. Isn't this weird? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To think is to differ. -Clarence Darrow __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
just try doing it with === (three equal signs) and you'll see what is where -- Maxim Maletsky [EMAIL PROTECTED] Cal Evans [EMAIL PROTECTED] wrote... : John. Actually, 08 is equal to 8 in PHP. PHP will convert the string to an integer and the two will compare as equal. No they are not equal. Yes, PHP will do the conversion so that they are equal. That does not refute the fact that logically '08' != 8. Someone already posted why the problem was happening, because the numbers were being converted to invalid octal numbers and being set to zero. I understand the problem at hand. (and did when I posted) However, if Scott had been doing the conversions manually, he would never have run across this problem. It is a bad idea to rely on the language (whatever the language) to do automatic variable conversions. =C= -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Your bug is this:
inconsistency of types.
You split a formatted string into smaller strings and compare the
integers to it. In order to do this correctly, you will need to take
your integers and convert them into the strings, format of which you
already know and used for deformatting the original string. Then compare.
That is the only way to be safe, other ways are magic because PHP
debugged them for you. It's really all about the programming logic. few
of you who are fluent with C or Java would dump into this.
--
Maxim Maletsky
[EMAIL PROTECTED]
Scott Fletcher [EMAIL PROTECTED] wrote... :
Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with
why PHP code failed to work with the month is August or September, so I have
been playing around it and found the problem. I recently wrote a demo
script for you all to play around with. Let me know which PHP version does
this bug not affected you I'm going to file a PHP bug at
http://bug.php.net.. I'll let you know where PHP bug # is it. To tell
you the truth, I don't know how to search for existing bug on this one if
there is any because I don't know if it is an if-statement issue or if it is
something else Feel free to submit a patch if you know how.
Let me know what you found and post it here...
--clip--
?
//Sample Code. ==
$VARIABLE[0] = 2002-01;
$VARIABLE[1] = 2002-02;
$VARIABLE[2] = 2002-03;
$VARIABLE[3] = 2002-04;
$VARIABLE[4] = 2002-05;
$VARIABLE[5] = 2002-06;
$VARIABLE[6] = 2002-07;
$VARIABLE[7] = 2002-08;
$VARIABLE[8] = 2002-09;
$VARIABLE[9] = 2002-10;
$VARIABLE[10] = 2002-11;
$VARIABLE[11] = 2002-12;
//Loop Code to check the variable ===
for ($x=0;$x12;$x++) {
$month = substr($VARIABLE[$x],5,2);
echo The # of month is .$x.br;
if ($month == 01) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 02) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 03) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 04) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 05) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 06) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 07) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 08) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 09) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 10) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 11) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
if ($month == 12) { echo It's a Match!!br; } else { echo It's not
a Match!!br; }
echo br;
}
//Strange Workaround to 08 and 09 ===
echo Strange Workaround to the Problem!!brbr;
$month = substr($VARIABLE[7],5,2);
echo The # of month is 08br;
if (trim($month) == 8) {
echo It's working!!!br;
}
$month = substr($VARIABLE[8],5,2);
echo The # of month is 09br;
if (trim($month) == 9) {
echo It's working!!!br;
}
//Testing (Should this be working or not??) =
echo brbr;
$month = substr($VARIABLE[0],5,2);
echo The # of month is 1br;
if (trim($month) == 1) { //With 1 as an integer...
echo It's working!!!br;
}
echo br;
$month = substr($VARIABLE[0],5,2);
echo The # of month is 01br;
if (trim($month) == 01) { //With 01 as an integer
echo It's working!!!br;
}
echo br;
$month = substr($VARIABLE[0],5,2);
echo The # of month is 1br;
if (trim($month) == 1) { //With 1 as an integer...
echo It's working!!!br;
}
echo br;
$month = substr($VARIABLE[0],5,2);
echo The # of month is 01br;
if (trim($month) == 01) { //With 01 as an integer
echo It's working!!!br;
}
?
--clip--
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
On Tuesday 28 January 2003 03:56, Scott Fletcher wrote:
Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with
why PHP code failed to work with the month is August or September, so I
have been playing around it and found the problem. I recently wrote a demo
script for you all to play around with. Let me know which PHP version does
this bug not affected you I'm going to file a PHP bug at
http://bug.php.net.. I'll let you know where PHP bug # is it. To tell
you the truth, I don't know how to search for existing bug on this one if
there is any because I don't know if it is an if-statement issue or if it
is something else Feel free to submit a patch if you know how.
Let me know what you found and post it here...
--clip--
[snip]
if ($month == 01) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 02) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 03) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 04) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 05) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 06) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 07) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 08) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
if ($month == 09) { echo It's a Match!!br; } else { echo It's
not a Match!!br; }
Have a look at the manual Types Integers
--
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems Integrators
* Web Design Hosting * Internet Intranet Applications Development *
/*
I'm having a BIG BANG THEORY!!
*/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Found a PHP bug!!!!!!!!!
-Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
I don't see why a string wouldn't work when I use 08 (string) and match it against the integer 8, or 08. Kirk Johnson [EMAIL PROTECTED] wrote in message B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef">news:B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef... -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
--- Scott Fletcher [EMAIL PROTECTED] wrote: Found a PHP bug ... if ($month == 01) I guess you mean: if ($month == '01') If so, this is not a bug. Otherwise, please explain what you think is wrong. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Found a PHP bug!!!!!!!!!
Scott, Because 8 != 8. 8 (and 08) is a string with the numerals representing the number eight. It is not the number eight. (think back to basic math, the difference between a number and a numeral) PHP does some conversions for you automatically but that just saves you from yourself. (Personally, I wish it wouldn't. People have more trouble *because* of the automatic conversions than they would if they had to do the converting themselves.) To keep from running into this simply do the conversions yourself before you do comparisons. intval(08)==8 =C= * * Cal Evans * Stay plugged into your audience. * http://www.christianperformer.com * -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 2:14 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] Found a PHP bug! I don't see why a string wouldn't work when I use 08 (string) and match it against the integer 8, or 08. Kirk Johnson [EMAIL PROTECTED] wrote in message B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef">news:B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef... -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Re: [PHP] Found a PHP bug! uh oh... I don't see why a string wouldn't work when I use 08 (string) and match it against the integer 8, or 08. They're just different types. Normally PHP is veeery flexible with types, like javascript, but it just can't be flexible for you here because it needs to choose the most logic to the entire pool of programmers, and then 08 = a string 8 = a decimal integer 08 = by definition an impossible octal integer, so 0. Since you cannot tell PHP that $var is of a certain type like in [other] programming languages, for example you want it to be treated as an integer, PHP will handle it as what seems to be the most logic. You can try to use intval (does not alter a variable, only the value as it is used in a calculation or an if() statement) or settype (alters the variable). Kirk Johnson [EMAIL PROTECTED] wrote in message B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef">news:B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef... -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
I'm referring to '08' and '09' that don't work Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Scott Fletcher [EMAIL PROTECTED] wrote: Found a PHP bug ... if ($month == 01) I guess you mean: if ($month == '01') If so, this is not a bug. Otherwise, please explain what you think is wrong. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
I do know that integer, string, double, float, etc are different.. I have been using hte appropriate method like in javascript and c programming, like converting it to integer and so on But when I start using PHP, I find no such document of it and I have been using it for 3 years without a problem. I asked people is there such a thing as converting it by using the function and they told me there is no such a thing and that it is done automatically... Now my time is a little bit wasted. So, I will correct the problem with the php script... I recently looked up on the manual as Jason Wong instructed me to. I havne't found the answer since the document is a little bit mixed up. Okay, I'm going back to my old way as I did in javascript and c programming. So for php, it would be floatval() for float... strval() for string settype() for whatever.. intval() for integer Um, what about double??? Thanks, Scott F. Chris Hayes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Re: [PHP] Found a PHP bug! uh oh... I don't see why a string wouldn't work when I use 08 (string) and match it against the integer 8, or 08. They're just different types. Normally PHP is veeery flexible with types, like javascript, but it just can't be flexible for you here because it needs to choose the most logic to the entire pool of programmers, and then 08 = a string 8 = a decimal integer 08 = by definition an impossible octal integer, so 0. Since you cannot tell PHP that $var is of a certain type like in [other] programming languages, for example you want it to be treated as an integer, PHP will handle it as what seems to be the most logic. You can try to use intval (does not alter a variable, only the value as it is used in a calculation or an if() statement) or settype (alters the variable). Kirk Johnson [EMAIL PROTECTED] wrote in message B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef">news:B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef... -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Whoop! FOund it, it is doubleval()... What does settype() do exactly Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I do know that integer, string, double, float, etc are different.. I have been using hte appropriate method like in javascript and c programming, like converting it to integer and so on But when I start using PHP, I find no such document of it and I have been using it for 3 years without a problem. I asked people is there such a thing as converting it by using the function and they told me there is no such a thing and that it is done automatically... Now my time is a little bit wasted. So, I will correct the problem with the php script... I recently looked up on the manual as Jason Wong instructed me to. I havne't found the answer since the document is a little bit mixed up. Okay, I'm going back to my old way as I did in javascript and c programming. So for php, it would be floatval() for float... strval() for string settype() for whatever.. intval() for integer Um, what about double??? Thanks, Scott F. Chris Hayes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Re: [PHP] Found a PHP bug! uh oh... I don't see why a string wouldn't work when I use 08 (string) and match it against the integer 8, or 08. They're just different types. Normally PHP is veeery flexible with types, like javascript, but it just can't be flexible for you here because it needs to choose the most logic to the entire pool of programmers, and then 08 = a string 8 = a decimal integer 08 = by definition an impossible octal integer, so 0. Since you cannot tell PHP that $var is of a certain type like in [other] programming languages, for example you want it to be treated as an integer, PHP will handle it as what seems to be the most logic. You can try to use intval (does not alter a variable, only the value as it is used in a calculation or an if() statement) or settype (alters the variable). Kirk Johnson [EMAIL PROTECTED] wrote in message B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef">news:B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef... -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
I would need to use intval() to solve this problem Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I'm referring to '08' and '09' that don't work Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Scott Fletcher [EMAIL PROTECTED] wrote: Found a PHP bug ... if ($month == 01) I guess you mean: if ($month == '01') If so, this is not a bug. Otherwise, please explain what you think is wrong. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
U might want to do a type cast to integer from string... http://www.php.net/manual/en/language.types.type-juggling.php On Mon, 2003-01-27 at 13:47, Scott Fletcher wrote: I would need to use intval() to solve this problem Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I'm referring to '08' and '09' that don't work Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Scott Fletcher [EMAIL PROTECTED] wrote: Found a PHP bug ... if ($month == 01) I guess you mean: if ($month == '01') If so, this is not a bug. Otherwise, please explain what you think is wrong. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Because 8 != 8. 8 (and 08) is a string with the numerals representing the number eight. It is not the number eight. (think back to basic math, the difference between a number and a numeral) Actually, 08 is equal to 8 in PHP. PHP will convert the string to an integer and the two will compare as equal. PHP does some conversions for you automatically but that just saves you from yourself. (Personally, I wish it wouldn't. People have more trouble *because* of the automatic conversions than they would if they had to do the converting themselves.) Someone already posted why the problem was happening, because the numbers were being converted to invalid octal numbers and being set to zero. Run this bit of code for an example: echo br . ((01 == 1) ? Match : No Match); echo br . ((02 == 2) ? Match : No Match); echo br . ((03 == 3) ? Match : No Match); echo br . ((04 == 4) ? Match : No Match); echo br . ((05 == 5) ? Match : No Match); echo br . ((06 == 6) ? Match : No Match); echo br . ((07 == 7) ? Match : No Match); echo br . ((08 == 8) ? Match : No Match); echo br . ((09 == 9) ? Match : No Match); The last two won't match because 08 and 09 are invalid octal numbers, like Kirk Johnson already said. So 08 != 08 and 8 != 08, for example. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
No, it's floatval. Doubleval is an alias left over from hwen floats were called doubles... Scott Fletcher wrote: Whoop! FOund it, it is doubleval()... What does settype() do exactly Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I do know that integer, string, double, float, etc are different.. I have been using hte appropriate method like in javascript and c programming, like converting it to integer and so on But when I start using PHP, I find no such document of it and I have been using it for 3 years without a problem. I asked people is there such a thing as converting it by using the function and they told me there is no such a thing and that it is done automatically... Now my time is a little bit wasted. So, I will correct the problem with the php script... I recently looked up on the manual as Jason Wong instructed me to. I havne't found the answer since the document is a little bit mixed up. Okay, I'm going back to my old way as I did in javascript and c programming. So for php, it would be floatval() for float... strval() for string settype() for whatever.. intval() for integer Um, what about double??? Thanks, Scott F. Chris Hayes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Re: [PHP] Found a PHP bug! uh oh... I don't see why a string wouldn't work when I use 08 (string) and match it against the integer 8, or 08. They're just different types. Normally PHP is veeery flexible with types, like javascript, but it just can't be flexible for you here because it needs to choose the most logic to the entire pool of programmers, and then 08 = a string 8 = a decimal integer 08 = by definition an impossible octal integer, so 0. Since you cannot tell PHP that $var is of a certain type like in [other] programming languages, for example you want it to be treated as an integer, PHP will handle it as what seems to be the most logic. You can try to use intval (does not alter a variable, only the value as it is used in a calculation or an if() statement) or settype (alters the variable). Kirk Johnson [EMAIL PROTECTED] wrote in message B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef">news:B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef... -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- The above message is encrypted with double rot13 encoding. Any unauthorized attempt to decrypt it will be prosecuted to the full extent of the law.
Re: [PHP] Found a PHP bug!!!!!!!!!
Even doing a type cast won't make a difference for the original problem. Even if you cast 08 to an integer and compare it to 08 (invalid octal number), it'll still fail. The original solution was the best, remove the leading zero from the comparisons and let PHP handle the type casting. ---John Holmes... - Original Message - From: Ray Hunter [EMAIL PROTECTED] To: Scott Fletcher [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 3:45 PM Subject: Re: [PHP] Found a PHP bug! U might want to do a type cast to integer from string... http://www.php.net/manual/en/language.types.type-juggling.php On Mon, 2003-01-27 at 13:47, Scott Fletcher wrote: I would need to use intval() to solve this problem Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I'm referring to '08' and '09' that don't work Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Scott Fletcher [EMAIL PROTECTED] wrote: Found a PHP bug ... if ($month == 01) I guess you mean: if ($month == '01') If so, this is not a bug. Otherwise, please explain what you think is wrong. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Found a PHP bug!!!!!!!!!
John. Actually, 08 is equal to 8 in PHP. PHP will convert the string to an integer and the two will compare as equal. No they are not equal. Yes, PHP will do the conversion so that they are equal. That does not refute the fact that logically '08' != 8. Someone already posted why the problem was happening, because the numbers were being converted to invalid octal numbers and being set to zero. I understand the problem at hand. (and did when I posted) However, if Scott had been doing the conversions manually, he would never have run across this problem. It is a bad idea to rely on the language (whatever the language) to do automatic variable conversions. =C= -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Yea, it's too bad that not many people know about it. I first asked and they told me it is done automatically. That was 3 years ago. I never had a problem for 3 years until now. So, I'm going back to the old way as I did in Javascript and C programming. I first started PHP 3 years ago, so it's no wonder why there's all the confusion when I was just an innocent victim. :-) Cal Evans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... John. Actually, 08 is equal to 8 in PHP. PHP will convert the string to an integer and the two will compare as equal. No they are not equal. Yes, PHP will do the conversion so that they are equal. That does not refute the fact that logically '08' != 8. Someone already posted why the problem was happening, because the numbers were being converted to invalid octal numbers and being set to zero. I understand the problem at hand. (and did when I posted) However, if Scott had been doing the conversions manually, he would never have run across this problem. It is a bad idea to rely on the language (whatever the language) to do automatic variable conversions. =C= -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Double and Float are not exactly the same thing. Double is --- 11.123 Float is -- .00238823993 Leif K-Brooks [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... No, it's floatval. Doubleval is an alias left over from hwen floats were called doubles... Scott Fletcher wrote: Whoop! FOund it, it is doubleval()... What does settype() do exactly Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I do know that integer, string, double, float, etc are different.. I have been using hte appropriate method like in javascript and c programming, like converting it to integer and so on But when I start using PHP, I find no such document of it and I have been using it for 3 years without a problem. I asked people is there such a thing as converting it by using the function and they told me there is no such a thing and that it is done automatically... Now my time is a little bit wasted. So, I will correct the problem with the php script... I recently looked up on the manual as Jason Wong instructed me to. I havne't found the answer since the document is a little bit mixed up. Okay, I'm going back to my old way as I did in javascript and c programming. So for php, it would be floatval() for float... strval() for string settype() for whatever.. intval() for integer Um, what about double??? Thanks, Scott F. Chris Hayes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Re: [PHP] Found a PHP bug! uh oh... I don't see why a string wouldn't work when I use 08 (string) and match it against the integer 8, or 08. They're just different types. Normally PHP is veeery flexible with types, like javascript, but it just can't be flexible for you here because it needs to choose the most logic to the entire pool of programmers, and then 08 = a string 8 = a decimal integer 08 = by definition an impossible octal integer, so 0. Since you cannot tell PHP that $var is of a certain type like in [other] programming languages, for example you want it to be treated as an integer, PHP will handle it as what seems to be the most logic. You can try to use intval (does not alter a variable, only the value as it is used in a calculation or an if() statement) or settype (alters the variable). Kirk Johnson [EMAIL PROTECTED] wrote in message B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef">news:B11731D518B5D61183C700A0C98BE0D9FFBE5D@chef... -Original Message- From: Scott Fletcher [mailto:[EMAIL PROTECTED]] Found a PHP bug, I'm using PHP version 4.2.3. I have been struggling with why PHP code failed to work with the month is August or September I stumbled into this one a short while ago myself. It is not a bug, but a feature! ;) When passing values of 08 or 09 (Aug and Sep), PHP interprets them as octal numbers (because of the leading 0). However, 08 and 09 are invalid octal numbers, so PHP converts them to zero. The fixes are numerous: - remove the leading zero; - add zero to them before passing (addition forces a type conversion to int); - force a type conversion to integer using (int); - quote them (when PHP converts a string to an integer, it removes the leading zero); Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- The above message is encrypted with double rot13 encoding. Any unauthorized attempt to decrypt it will be prosecuted to the full extent of the law. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Aw nut!!! The intval() doesn't work.. I had enough, I'm going to do what Kirk Johnson recommend. That one work better. Scott Fletcher [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Yea, it's too bad that not many people know about it. I first asked and they told me it is done automatically. That was 3 years ago. I never had a problem for 3 years until now. So, I'm going back to the old way as I did in Javascript and C programming. I first started PHP 3 years ago, so it's no wonder why there's all the confusion when I was just an innocent victim. :-) Cal Evans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... John. Actually, 08 is equal to 8 in PHP. PHP will convert the string to an integer and the two will compare as equal. No they are not equal. Yes, PHP will do the conversion so that they are equal. That does not refute the fact that logically '08' != 8. Someone already posted why the problem was happening, because the numbers were being converted to invalid octal numbers and being set to zero. I understand the problem at hand. (and did when I posted) However, if Scott had been doing the conversions manually, he would never have run across this problem. It is a bad idea to rely on the language (whatever the language) to do automatic variable conversions. =C= -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Found a PHP bug!!!!!!!!!
Another workaround to this problem is as an addition to Kirk Johnson's
suggestion
--clip--
$month = 08;
if (trim($month) == 8) {
echo You got it!!!;
}
--clip--
Scott Fletcher [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Aw nut!!! The intval() doesn't work.. I had enough, I'm going to do
what Kirk Johnson recommend. That one work better.
Scott Fletcher [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Yea, it's too bad that not many people know about it. I first asked and
they told me it is done automatically. That was 3 years ago. I never
had
a
problem for 3 years until now. So, I'm going back to the old way as I
did
in Javascript and C programming. I first started PHP 3 years ago, so
it's
no wonder why there's all the confusion when I was just an innocent
victim.
:-)
Cal Evans [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
John.
Actually, 08 is equal to 8 in PHP. PHP will convert the string to
an
integer and the two will compare as equal.
No they are not equal. Yes, PHP will do the conversion so that they
are
equal. That does not refute the fact that logically '08' != 8.
Someone already posted why the problem was happening, because the
numbers
were being converted to invalid octal numbers and being set to zero.
I understand the problem at hand. (and did when I posted) However, if
Scott
had been doing the conversions manually, he would never have run
across
this
problem. It is a bad idea to rely on the language (whatever the
language)
to do automatic variable conversions.
=C=
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
