Adam
" 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."
I know a zero length string is not the same as a NULL value. But in CFML, if
something is NULL, then yes your right, it is
something that has not been initialized yet, for example, arrays in CFML. If a
variable has been initialized but set as an empty
string, then its value is an empty string, not NULL.
>From what I gather, CFML does not handle outputting of a NULL value, because for
>CFML, if something is NULL, then it has not been
initialized and does not have a value and will error with a not defined error.
With your example, #len("ABCD#chr(0)#FGHIJ")#, of course its going to output 9 cause
cf doesn't see it as NULL in the sense of the
term, it sees it as an empty string, not a NULL char. Using the Chr() function
outputs the value of the chr you enter. Chr(9) is a
TAB for example. Its value is a TAB space and will output that. If chr(0) is a NULL
chr, then its going to output just that, NULL.
You may have to actually do it using java, or another language that is of type and
will treat the NULL as you are expecting it to be
rather than the nothing which cf is treating it
Steve
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Cameron
Sent: Sunday, September 19, 2004 6:13 PM
To: CFAussie Mailing List
Subject: [cfaussie] Re: cfoutputting the 'null' char
> 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/
---
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/
