tracker issue : CF-3696455

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

Internal CFC functions return string variables with a strange non-trimmable preceeding space

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): Ari-Ville Fernelius / Ari-Ville Fernelius (Fernis)

Created: 01/20/2014

Components: Language, CF Component

Versions: 10.0

Failure Type: Non Functioning

Found In Build/Fixed In Build: Final /

Priority/Frequency: Critical / Most users will encounter

Locale/System: English / Win 2008 Server R2

Vote Count: 0

Problem Description: CFCs cannot use internal functions to return strings, as they return incorrect and unusable values. Real life case: making CFCs extend utilify.cfc which contains common functions, such as createGUID(). In CF's opinion, returned value is 36 characters long, but it's actually 37, cannot be trimmed. As a result, it cannot be inserted into database with any other workaround but removing the internal CFC function, and replacing it with an external function call to another CFC.

Steps to Reproduce:

mytest.cfm

<cfinvoke component="test.cfc" method="tester">


test.cfc:

<cfcomponent>
  <cfprocessingdirective pageencoding="utf-8">
 
  <cffunction name="createA" returntype="string">
    <cfreturn "A">
  </cffunction>
 
  <cffunction name="tester">
  <cfoutput>[#createA()#], length: #len(createA())#, first character: [#left(createA(),1)#]</cfoutput>
  </cffunction>
</cfcomponent>

Actual Result: [ A], 1, [ A]

Expected Result: [A], 1, [A]

Any Workarounds: CFCs must not extend a utility library with common functions. Instead, all utility functions must be copy-pasted to every CFC, which is most cumbersome, adds codebase hugely, leads to more bugs and typos, etc.

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

Watson Bug ID:	3696455

External Customer Info:
External Company:  
External Customer Name: Fernis
External Customer Email:  
External Test Config: My Hardware and Environment details: Tested under Windows Server 2008R2 with CF10 updater 10,  Windows 7 with CF 10 updater 13 (latest)

Attachments:

Comments:

Of course, another pretty easy workaround is to invoke the method from another CFC with cfinvoke, for example. Just as long as it's called from an external CFC, it works. Will break, however, if the calling CFC method extends the other CFC, and invocation is not done explicitly from an external CFC.
Comment by External U.
13631 | January 20, 2014 10:45:39 PM GMT
Using createobject() to create an instance to an external CFC does not work either. The returned function result is corrupted. Cfinvoke must be used. For example, utility.cfc: <cffunction name="createC"><cfreturn "C"></cffunction> test.cfc: <cfobject type="component" name="util" component="utility"><cfoutput>#util.createC()#</cfoutput> This will also return a corrupted result, " C" instead of "C", CF still thinking the return value length is 1. Something very strange is going on...
Comment by External U.
13632 | January 21, 2014 02:02:27 AM GMT
This is not a bug but a known behavior with ColdFusion. As functions can also generate output/html in CF all the whitespace generated is pushed to output and hence you are seeing a leading space, its not that the return variable has any extra space. CFInvoke does not generate that space because you take its returned variable and cfoutput it. To remove that space use output="false" with cffunction. CreateObject works similar to cfinvoke.
Comment by Chandan ..
13633 | January 21, 2014 02:33:18 AM GMT
Thanks, Chandan for clearing this out. I was relying on cfcomponent output="false" to do the trick for me, and had forgotten I have to specify for the functions as well. I started to question my logic when even #asc(createA())# gave me [ 97] with the space, which had to mean that the returned value is not the one that is corrupted. This one may be closed, being an example of how important it is to remember to set output to false for functions. This issue may be closed as resolved.
Comment by External U.
13634 | January 21, 2014 05:14:32 AM GMT