Copy link to clipboard
Copied
Running CF 9 on Linux, the following produces unusual results:
<cfscript>
a = { '99' = "that", '8X' = "this"};
writedump(a);
</cfscript>
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:
<cfscript>
blah['GNQ'] = 'bad struct';
blah['H02'] = 'worse struct';
</cfscript>
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:
<cfscript>
testb0 = "test";
testao = "test2";
</cfscript>
This produces an error page with the message "can't load a null". However, the following is possible:
<cfscript>
testb0 = "test";
writeoutput("b0 = #testb0#<br/>");
writeoutput("ao = #variables['testao']#<br/>");
writeoutput("#structkeyexists(variables, "testao")#");
</cfscript>
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.
Copy link to clipboard
Copied
Running CF 9 on Linux, the following produces unusual results: <cfscript>
a = { '99' = "that", '8X' = "this"};
writedump(a);</cfscript>
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:
Same one Windows.
Have you raised a bug for this?
http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html
?
--
Adam
Copy link to clipboard
Copied
I have a similar problem. Has anyone identified a workaround?
After some experimenting I have reduced the test case to the following code
<CFSET Q3="abc">
<CFSET PR="123">
<CFOUTPUT>#Q3#</CFOUTPUT>
Changing PR to PX resolves this particular case, but am still getting the "can't load a null" error in my application, and as of yet have not been able to resolve it. This is a showstopper for us at this point for going to CF9. Reported this bug to Adobe (bug #82491). It was closed as duplicate, but not sure which bug report it was a duplicate of, and not sure when the fix for it will be made available.
I am running CF9 on Windows Server 2003 with IIS. I have applied "Cumulative Hot Fix 1 for Coldfusion 9" with no effect on this issue.
P.S., Is there a way to be notified of Hot Fix releases?
Copy link to clipboard
Copied
Hi Mr. Fungus -
There has indeed been a hot fix released:
http://kb2.adobe.com/cps/825/cpsid_82547.html
Not sure if there is a way to be notified of releases for that kind of thing. We filed a bug and provided documentation, but only found out about the hot fix from forums.
The hot fix solved the issue for us - hope you have the same results!
Copy link to clipboard
Copied
buglug,
Hm. I applied the hotfix that you referenced but it unfortunately didn't fix my problem. But I'm thankful for the quick reply. I'm curious to know if the following results in "can't load a null" for you under your CF9 installation? (or anyone else reading this thread) Also would be curious if anyone knows when the fix for this might be released in a cumulative hot fix or patch? Thanks!
test.cfm:
<CFSET Q3="abc">
<CFSET PR="123">
<CFOUTPUT>#Q3#</CFOUTPUT>
Copy link to clipboard
Copied
I ran your test code on an unpatched V9, got the null pointer error. Applied the hotfix, reran, it worked fine
- got the "123" output
Did you restart CF after applying the hotfix?
-reed
Copy link to clipboard
Copied
I did restart but turns out I fed the updater the zip file (hf900-81860.zip) instead of the jar file (hf900-81860.jar). Now it returns the correct results, "abc" (not "123"). I also confirmed that this problem was not fixed by "Cumulative Hot Fix 1 for Coldfusion 9". And, I verified that it fixed the more widespread issue in my application. Thank you guys!
HotFix (thanks buglug):
http://kb2.adobe.com/cps/825/cpsid_82547.html
Related bugIDs:
81860
81884
82491
Related posts: