tracker issue : CF-3877103

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

Inconsistent handling of coercing booleans to numerics

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

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

Created: 12/12/2014

Components: Language

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / Some users will encounter

Locale/System: ALL / Platforms All

Vote Count: 3

Consider this:
<cfoutput>
#val(true)#
#val(false)#
#val("true")#
#val("false")#
#val("yes")#
#val("no")#
</cfoutput>

Outputs:
0 0 0 0 0 0

Now this:
<cfoutput>
#true * 1#
#false * 1#
#"true" * 1#
#"false" * 1#
#"yes" * 1#
#"no" * 1#
</cfoutput>

Outputs:
1 0 1 0 1 0

I can see arguments for both of these returning either "0 0 0 0 0 0" or "1 0 1 0 1 0", but it's not correct for them each to return different results.

FWIW, Railo gets this right, returning "1 0 1 0 1 0" for both. As one would expect.

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

Watson Bug ID:	3877103

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

Attachments:

Comments:

+1 - and I'd be interested in knowing which bug fix(es) created this issue
Vote by External U.
9421 | December 12, 2014 06:34:54 PM GMT
+1 /////////////////////////////////////
Vote by External U.
9422 | December 13, 2014 07:29:43 AM GMT
+1 /////////////////////////
Vote by External U.
9423 | December 13, 2014 03:13:19 PM GMT
The comparison is not between similar things. Val function converts numeric characters that occur at the beginning of a string to a number. https://wikidocs.adobe.com/wiki/display/coldfusionen/Val It expects a string. So we should keep it as a string. (Whether we should accept true without quotes is debatable) #"true" * 1# tries to convert the string to numeric because we are expecting a numeric there.
Comment by Himavanth R.
9415 | January 07, 2015 08:34:03 AM GMT
That's fair enough. So is TRUE being coerced into "TRUE"? I'm OK for this one to be closed. Cheers Himavanth
Comment by External U.
9416 | January 08, 2015 07:05:48 AM GMT
> So is TRUE being coerced into "TRUE"? Booleans treated as strings generally get converted to "yes"/"no"
Comment by External U.
9417 | January 08, 2015 09:34:12 AM GMT
Good point. But the crux of it is that's it's not being coerced to something with a numeric value, as one might expect. Indeed, as everyone who I asked actually did expect. Still: there's logic to the approach, so agree it's not a bug, nor worth further addressing.
Comment by External U.
9418 | January 08, 2015 09:38:40 AM GMT
Yeah, I was initially thinking that too, but (as you/Himavanth say) it makes sense that val takes a string. I was mainly just clarifying the true->"yes" thing for the benefit of others - I had also started moaning about how it is ends up as yes in the first place, that CF only has YesNoFormat but no TrueFalseFormat, and the whole having to prepend a space to strings to stop them being converted stuff - but then decided that was all off-topic.
Comment by External U.
9419 | January 08, 2015 10:09:31 AM GMT
One day I will find the person who decided CFML should have "yes" and "no" as boolean values... ... And say unpleasant things to them.
Comment by External U.
9420 | January 08, 2015 10:22:55 AM GMT