Anyone know why Adobe and Lucee both return an emp...
# cfml-general
b
Anyone know why Adobe and Lucee both return an empty string for the following expressions, instead of a proper null byte?
Copy code
chr(0)
I'm building out a STOMP broker in CF (which terminates each message with a null byte) and this worked as I expected in Boxlang, but I can see from Lucee's source code,
0
is a special case, hard-coded to return an empty string instead of a null byte, which is not the same thing!
I will point out I found a workaround on StackOverlow posted by Adam Cameron, which is to use this
Copy code
URLDecode( "%00" )
d
I'm guessing it's a remanent of when ACF had no concept of
null
, so they treated the null byte the same way they do
null
in a database.
1
b
interesting
I will point out a "null byte" is not the same as "null". Null is an actual null reference, whereas a "null" byte is a byte of all zeros.
But I suppose I could understand the precedent, as annoying as it is!
b
That's a curious find. Looks like a bug. The code
<cfset chr0=chr(0)>
<cfset nullByte1=URLDecode("%00","utf-8")>
<cfset nullByte2=charsetEncode( javacast("byte[]", [0] ), "utf-8")>
<cfoutput>
len(chr0): #len(chr0)# <br>
len(nullByte1): #len(nullByte1)# <br>
len(nullByte2): #len(nullByte2)# <br><br>
chr0 is nullByte1: #chr0 is nullByte1# <br>
chr0 is nullByte2: #chr0 is nullByte2# <br>
nullByte1 is nullByte2: #nullByte1 is nullByte2#
</cfoutput>
results in
Copy code
len(chr0): 0
len(nullByte1): 1
len(nullByte2): 1

chr0 is nullByte1: NO
chr0 is nullByte2: NO
nullByte1 is nullByte2: YES
b
Ooh, nice one with the
Copy code
charsetEncode( javacast("byte[]", [0] ), "utf-8")>
method of creating a null byte
Basically the url decode and the javacast methods both create a true null byte, whereas the chr() method just returns an empty string
I can tell from Lucee's source code it was done on purpose as there is a special check for it. There's no real way to tell if Adobe ever did it on purpose or if it was just on accident and Lucee simply followed suite.
Hmm, your example uncovered a bug in BoxLang's
charsetEncode()
BIF 🙂
m
@nimitsharma please review here.
👍 2
n
This has been the case since the beginning in CF, but it doesn’t seem like the correct behavior. Fixing it might cause backward compatibility issues. Regardless, please log a bug for this issue, and we’ll investigate. Let me know if you’d prefer me to log the bug.
❤️ 1
b
If you could throw a bug report in the tracker for me, that would be great
b
👍 1