6 Replies Latest reply on Mar 25, 2010 2:57 PM by cold_fungus

    CF9 struct key and variable name problem


      Running CF 9 on Linux, the following produces unusual results:



          a = { '99' = "that", '8X' = "this"};



      The dump shows only the keypair with the key '99' and the value 'this'. #a['99']# produces "this". #a['8X']# produces "this" as well. It's as though CF cannot distinguish between the tokens '99' and '8X'. Note that implicit assignment is not implicated:



          blah['GNQ'] = 'bad struct';
          blah['H02'] = 'worse struct';



      This yields a struct with one member per structcount(), with a key-value pair of GNQ='worse struct', but the key 'H02' accesses the same value. structkeyexists(blah, 'H02') returns true.


      On our systems (we've tried CF 9 on separate RH 4 and RH5 machines) the problem is not limited to structs per se, and seems to persist even when other characters are involved in variable or struct key names:



          testb0 = "test";
          testao = "test2";



      This produces an error page with the message "can't load a null". However, the following is possible:



          testb0 = "test";

          writeoutput("b0 = #testb0#<br/>");

          writeoutput("ao = #variables['testao']#<br/>");

          writeoutput("#structkeyexists(variables, "testao")#");



      The above produces the output 'test' for the undeclared variable 'testao', and also thinks that variables.testao is in the variables scope, even though it hasn't been declared.


      A quick loop or two and we've found that our CF 9 installations cannot distinguish between 340 two letter sequences, in matched pairs, as in the following example:


      ao = B0
      ap = B1
      aq = B2
      ar = B3
      as = B4
      at = B5
      au = B6
      av = B7
      aw = B8
      ax = B9


      Case does not seem to matter, and as mentioned above, this 'blindness' appears to persist even when the strings are embedded in other strings. E.g., when used as key or variable names, the following are being treated by CF as equal:


      slap = slb1

      tape = tb1e

      apes = b1es


      Has anyone else experienced anything like this? Could there be some strange setting that is causing CF to interpret the templates using some otherworldy codepage in which these characters are equivalent? Could there be something wrong with our installation, and/or our OS?


      Any hints, confirmation of our findings, and/or refutation of same would be greatly appreciated - we were hoping to move to CF 9 from CF 8 this week, but this is quite a showstopper for us.