tracker issue : CF-3731425

select a category, or use search below
(searches all categories and all time range)

Serious bug in #ColdFusion 11 BIFs-as-first-class-functions

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 03/27/2014

Components: Language

Versions: 2016,11.0,2018

Failure Type:

Found In Build/Fixed In Build: PublicBeta / 2018.0.0.311667

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 0

See comment here:

First the "small" issue i have found.

This works:

but this breaks:
function test(){

throws "Variable LEN is undefined."?!


when i call the template where this code is stored as follows /index.cfm?len=123 it breaks!!!
this means, i can break every application that passes BIFs as variable simply by adding the BIF name in the query_string!!!

The former is bad enougth, but the latter makes this new CF11 functionality inviable, IMO.


----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3731425

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:



In later version, an option in CF admin will be added to define the order of scopes search where in BIF can take priority over url/form scopes.
Comment by Awdhesh K.
13010 | August 04, 2014 01:39:11 AM GMT
User variables are given the preference over the BIF function so that existing application would continue to work. In the scenario given here, it would only break that particular request and would not impact anything else. It is similar to accessing a wrong URL intentionally and getting an error back. Deferring it.
Comment by Rupesh K.
13011 | November 17, 2014 12:28:08 AM GMT
Sigh. But the current behaviour *doesn't* conform to standard CF behaviour when resolving scopes. When something is unscoped (as a ref to a BIF is, for all intents and purposses), then CF takes the unscoped one, not the URL one. The behaviour you have implemented here breaks that. Demonstration: <cfscript> varToUse = "the one in the variables scope"; writeOutput("When accessing an unscoped variable with equivalents in variables and URL scopes I use #varToUse#<br>"); function f(x){ writeDump(x); } writeOutput("But if the URL-scoped variable overlaps a built-in function:"); f(mid); </cfscript> Now pass this on the URL: ?varToUse=the%20one%20in%20the%20URL%20scope&mid=the%20one%20in%20the%20URL%20scope In this example for the *variable* it uses the unscoped ref, but for the function it favours the URL scope. This does *not* conform to expected behaviour. I don't make this shit up, Rupesh: I raise it for a reason.
Comment by External U.
13012 | November 17, 2014 02:59:30 AM GMT
This is how variables are resolved and ColdFusion always would look at the implicit scopes like URL scope to resolve it. In your case, your variable is defined in the variable scope and that gets the preference over the implicit scopes like CGI, URL, FORM, Cookie etc. Try this code a.cfm --------- <cfscript> myvar = y; writeoutput(myvar); </cfscript> --------- Access it using /a.cfm?y=10 It would output "10". In this case, since ColdFusion can't find the variable 'y' in local scope and variable scope, it would fall back to the implicit scopes to resolve it. BIFs are resolved at the end of variable resolution so that it does not conflict with any variable in the user's application and does not change the behavior of your application.
Comment by Rupesh K.
13013 | November 17, 2014 05:33:11 AM GMT
The case reported in this bug works when the flag this.searchImplicitScopes is set to false. The flag was introduced in CF 2016. Hence closing this bug.
Comment by Suchika S.
29929 | November 14, 2018 06:00:26 AM GMT
Hi Adobe, I've confirmed this ticket was fixed in CF2016 per this.searchImplicitScopes=false, as noted by Suchika. However, this ticket is not listed in CF2016's list of bugs fixed. Can it please be listed here?: Thanks!, -Aaron
Comment by Aaron N.
29991 | December 03, 2018 10:25:59 AM GMT