strtr VS CI bug? result parse error

[eluser]metaltapimenye[/eluser]
hi guys.. i think i found kind of bug while migrating old system on my office.
conditions:
fetching array trough native while() => mysql_fetch_assoc().

controler:

Code:

<?php
class Welcome extends Controller {

    function Welcome(){
          parent::Controller();
        }
        function index(){
        $this->load->view('old/something');
    }
        function bug(){
          $this->load->view('old/bug');
        }
}

view/old/bug.php

Code:

<?php
$s=mysql_query('select * from promotion where 1 /*promoend >= CURDATE()*/ order by promoid desc');
$c=mysql_num_rows($s);
$d=date('Ymd');
    
while($r=mysql_fetch_assoc($s)){
  ##bug(?) notice: start
  echo $c=(strtr($r['promoend'],array(" "=>"","-"=>"",":"=>""))>$d)?'#caffca':'#e9e9e9';
  ##notice:end
}?>

related route:

Code:

$route['^(?!test).*'] = "welcome/$0";

url hit: http://localhost/CI_Dir/bug

result:
Parse error: parse error in C:\wamp\www\CI_Dir\system\application\views\old\bug.php on line (line_num)

note:i use index.php cleanup .htaccess

its running well when i replace and reassign the variable [notice] part to..

Code:

$new_var=strtr($r['promoend'],array(" "=>"","-"=>"",":"=>""));
echo $c=($new_var > $d)?'#caffca':'#e9e9e9';

thx

[eluser]mddd[/eluser]
I think the problem is that there is an unclear situation here. The expression can mean two things:

echo ($c=(condition)) ? opt1 : opt2
or
echo $c = ( (condition) ? opt1: opt2)

See the difference? php needs to know whether the choice ( the ? operator) applies only to the strtr>$d operation or to the entire expression, which is $c = strtr > $d.
That is why it DOES work in your second example. Here there is no ambiguity about what the ? operation means.

[eluser]metaltapimenye[/eluser]
@mddd whoa.. i lost it did you mean its a typo?
i think its quiet clear that first notice part should be read

echo;
-->result_condition
---->compare_start:{
------> result_oftrtr($var1,$var2)
---->operand_on:">"
------> value_of:$d
---->compare_end:}
----> result:true->return opt1
----> result:else->return opt2
execute;

im sorry if i have to describe it in unusual diagram, 'coz i dont know how better ways to describe it

any how, i use CI because it can accommodate most of native PHP style without making any changes for how's command will interpret and default PHP behavior. Since those style of comparison works on native code style, on those assumptions i think i could migrate my old system more easily.

if my assumption was wrong, well sorry..

[eluser]mddd[/eluser]
No I don't think it has anything to do with CI. Maybe a difference in parsing between the versions of PHP you are using.
Anyway, it is clear how to solve it: split up the comparison over two lines, or add some brackets ( ) to tell PHP the right order of business.

[eluser]metaltapimenye[/eluser]
@mddd thx for fast reply. i dont think its about PHP versions. maybe i have to give a further notice that 3 code style (pure native,CI-buggy_method,CI-worked_out) applied and back-uped on same server (localhost, PHP v.5.0.3, wamp standard setting build).

The reason i still suggest it as a bug was related to optimizing stuff on "Don't copy variables for no reason" part. in this case, make $new_var was a set back.

imho

[eluser]mddd[/eluser]
I understand. Just try this for me, see if it works:

Code:

echo $c= ( (strtr($r['promoend'],array(" "=>"","-"=>"",":"=>""))>$d) ) ?'#caffca':'#e9e9e9';

[eluser]metaltapimenye[/eluser]
not working also mate..

[eluser]mddd[/eluser]
Sorry, that wasn't really a change in the code. How about this

Code:

echo $c= ( (strtr($r['promoend'],array(" "=>"","-"=>"",":"=>""))>$d)?'#caffca':'#e9e9e9' ) ;

[eluser]metaltapimenye[/eluser]
@mddd not working also mate..

o'yea.. i forgot to mention that i use CI v1.7.2

[eluser]mddd[/eluser]
Okay then I give up. I've had a similar issue one, where the order and grouping of things in the expression made a difference.. that's why I wanted to try it out.

But I really can't see how this could be related to Code Igniter, because a parse error is like php saying 'I don't understand this because it's written wrong'. I don't see how a CI bug could cause a php error like that.