Bug? Cfif typo SET a session variable

Jeramie_Gatchell · February 28, 2018, 6:15pm

Hello everyone,

I don’t know why, but i’ve always struggled remembering if CFIF uses IS or =. So i’m working on a project today and put = (instead of is) when checking a session var.

do this stuff

and i didn’t realize it, ran the code and was getting really unexpected behavior. i went back to the code and realized right away, “oh crap i put = again darn it!”

Typically i would expect a system to throw an error in this case, but instead it actually behaved like it was a and SET the session var to 1!

I wouldn’t think this is the desired behavior right?

i’m running:
Lucee 5.2.5.20
apache tomcat/8.5.11
java 1.8.0_121 64bit
windows server 2016 in a vmware vm

bdw429s · February 28, 2018, 8:35pm

Not a bug are all, just a typo on your part It’s actually a valid option to set a variable in your if. Here’s an example of me doing that in the condition for a while loop.

github.com

Ortus-Solutions/commandbox/blob/development/src/cfml/system/util/ProgressableDownloader.cfc#L53


      
          
          
		// Initialize status
          		var status = {
          			percent = 0,
          			speedKBps = 0,
          			totalSizeKB = -1,
          			completeSizeKB = 0
          		};
          
          
		try {
          
          
			var lengthOfFile = connection.getContentLength();
          
          
			var inputStream = createObject( 'java', 'java.io.BufferedInputStream' ).init( connection.getInputStream() );
          			var outputStream = createObject( 'java', 'java.io.FileOutputStream' ).init( arguments.destinationFile );
          
          
			var currentTickCount = getTickCount();
          			var lastTickCount = currentTickCount;
          			var kiloBytesPerSecondRunningAverage = [];
          			var lastKiloBytesPerSecond = 0;
          			var first = true;

Note, ACF isn’t cool enough to support this.

Jeramie_Gatchell · February 28, 2018, 8:56pm

Thanks for the reply so quickly!

So just to confirm, in lucee:

run this stuff

SHOULD set myvar to 1?

boy I better stop making THAT typo!!! lol

Thanks so much again.

Bradley · March 5, 2018, 6:41am

Can you name a use case for when a person would want this behavioral quirk in an if statement?

Loops. I understand, but otherwise this seems dangerous as in OP case.

The answer does seem tongue-in-cheek, but it’s worth risking the whoosh

Op—it might be easy to remember that cf kind of supports loose sentences. cfif variable is value and var2 does not contain “sub value”.

Bradley · March 5, 2018, 6:32pm

In some TryCF.com tests, I got some interesting results.

<cfscript>
    one = 0;
</cfscript>

<cfoutput>
    <cfif one = "1">#one#</cfif>
</cfoutput>

outputs 1, but

<cfscript>
    one = 0;
</cfscript>

<cfoutput>
    <cfif one = "test">#one#</cfif>
</cfoutput>

throws “Can’t cast String [test] to a boolean on line 6”

The edge-case situational mixed with cases where the syntax is valid are so rare, that I have to submit that it’s a detriment to devlopers.

I’ve also, in a few minutes’ testing, not been able to mix this with conditions like <cfif 2 eq 2 and one = 1>, throwing the expected "invalid-lefthand assignment>

In all these cases, if a developer absolutely wanted to set something in the if-line, they could write a function to do it. Even then, I can’t imagine why a cfset wouldn’t work better.

And none of this behavior even works in cfscript.

I think a lot of people tend to handle most of their logic in CFSCRIPT these days, but it still seems like asking for a security hole for tag-users making an innocent mistake.