binary in fields and strings

Alex Rice alex at
Thu Nov 13 14:04:06 EST 2003

On Nov 13, 2003, at 11:47 AM, Dar Scott wrote:

> Strings do just fine with ASCII NUL (0) and EOT (4).  The Revolution 
> EOF is encoded as 4, also.
> A few features have trouble with some values.  For example, you can't 
> have a NUL in an array key.
> I have seen (some versions back) NULs cause trouble in fields.  They 
> mess up display and the data gotten back is garbled.  The last I 
> looked, IIRC, the docs recommended avoiding any control characters in 
> fields other than tab and the end of line (LF in Rev).
> I don't know of a way somebody might type those.  I have some vague 
> memory of holding down some key and typing digits in Windows.  I have 
> not tried that with Revolution.

Typing isn't the problem for the most part - it's copy-pasting from 
other apps into a Rev field. I am going to implement pasteKey and do a 
replacetext in there - removing all the control characters that you 

> I am not sure I understand.
> Is this because you open a pipe to a process and that process looks 
> for the EOF character instead of a close?
> Or is this because it makes a mess of parsing?

Actually, it turns out the CLIPS docs were wrong- and it allows all 
characters in strings, except quotes are delimiters so must they 
escaped like \".

What happened however, did involve file IO and that's where the EOF 
caused trouble. The scenario was like this:

-- User pastes some text into Rev a app

-- Transcript handler gets the text and calls a CLIPS external function 
with that text as part of the parameter.

-- CLIPS runs, and saves it's state out to a file

-- CLIPS later reads the state in the file.

-- CLIPS finds EOF in the middle of a string and gives up parsing the 

> The limits, I think, to data passed to an external include the string 
> being null terminated and some sort of 64K limit.  I don't remember 
> whether the latter is for the entire call or a single parameter.
> If the CLIPS library has a character set limitation, it would be 
> reasonable to matchText() on that in any case.  I'd put that in and 
> then use that to track down the source.

Thanks for your feedback Dar! I had a feeling you would be the one to 
answer this one :-)

Alex Rice <alex at> | Mindlube Software | 

what a waste of thumbs that are opposable
to make machines that are disposable  -Ani DiFranco

More information about the Use-livecode mailing list