> Coldfusion is a typeless language, so NULL is just an empty string which will have
> no length
You're confusing two different things, and even then... not quite getting
it right.
A variable is considered to be null if it's been declared, but not
initialised. One cannot - for the most part(*) - do this in CF.
A zero-length string is not the same thing. A NULL string is one that's
been declared but not initialised. Not one that's been initialised as an
empty string. I'm not sure where typefulness comes into the equation here.
But what Tim is talking about is - as he states - chr(0), which in async
coms was referred to as the NULL character (cf chr(4) being EOT, chr(6)
being ACK, etc).
There's definitely a problem with CF here.
I extended Tim's test, thus:
#len("ABCD#chr(0)#FGHIJ")#
Now, I was half expecting this to output '4', as in many systems, the NULL
character is treated as an end-of-string marker, and I was thinking perhaps
CF was continuing that trend, and accordingly would truncate the string
it's evaluating when it encountered the end-of-string marker. Not so.
What it outputs is '9', which is clearly not the case; a chr(0) takes up as
much space as a letter 'E' (**), and should - accordingly - be included in
the length of the string.
So what I take to be happening is that CF *is* treating the chr(0)
character as an end of string marker, but at the same time, rather
confusingly, continuing to concatenate the trailing characters onto the
string anyhow. This is probably the WORST way the situation could be
handled, given a list of realistic possibilities.
Back to the actual issue.
Unfortunately, I scratched my head for a while, and could not come up with
a solution. I was going to suggest escaping the chr(0) character with
something else, but I - too - could not find a way to get CF to fess up to
the character even being there. Maybe circumvent CF completely and do it
in Java (my Java's too rusty for me to investigate a solution on a Sunday
night, sorry...).
Adam
(*)
<!___ this is the closest I can think to getting to declaring a variable
without initialising it --->
<cffunction name="null" returntype="void">
<cfreturn />
</cffunction>
<cfset z = null()>
This - in that the <cfset> line doesn't error, declares z, but doesn't
initialise it. The only problem is that CF can't handle it:
<cfoutput>
#isDefined("variables.z")#
#structKeyExists(variables, "z")#
</cfoutput>
Both return 'NO'
So I guess isDefined() and structKeyExists() both check for a value as well
as existence, which is a bit daft. But I guess fits in with the rest of CF
(not that it's daft, but that it's not aware of "null" as a concept).
If one then goes onto trying this:
<cfoutput>#z#<cfoutput>
We get an error stating that z is not defined.
(**)
In memory that string would be
0x41 (A)
0x42 (B)
0x43 (C)
0x44 (D)
0x00 (chr(0))
0x46 (F)
0x47 (G)
0x48 (H)
0x49 (I)
0x4A (J)
That's ten, not nine. CF should not ignore 0x00 any more than it should
ignore 0x01, 0xFF or anything in between. On the other hand, if it was to
treat 0x00 as a string-terminator, it should determine the length of that
string is four. It can't have it both ways.
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/
