• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

CF9 struct key and variable name problem

New Here ,
Jan 28, 2010 Jan 28, 2010

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.

TOPICS
Advanced techniques

Views

1.2K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Feb 12, 2010 Feb 12, 2010

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 24, 2010 Mar 24, 2010

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?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 24, 2010 Mar 24, 2010

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!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 25, 2010 Mar 25, 2010

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>

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Mar 25, 2010 Mar 25, 2010

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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Mar 25, 2010 Mar 25, 2010

Copy link to clipboard

Copied

LATEST

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:

http://stackoverflow.com/questions/2164472/bug-in-cf9-values-for-unique-struct-keys-referenced-and-o...

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation