In the course of developing a system which handles raw binary
information as strings, I found a curiosity in some initial
testing of STk/SNOW. While most Schemes seem to use the mem or b
functions or even raw loops for string manipulation, STk and SIOD
use the str functions. This means that in computation, a string
containing an embedded null maybe be treated as far shorter than
its actual length. Consider the following example:
(define a (list->string '(#\a #\a #\null #\b #\b)))
(define b (list->string '(#\a #\a #\null #\c #\c)))
Now what about this expression?
(string->list (string-append a b))
At this point you'd rather expect a list of length 10 of the form:
(#\a #\a #\null #\b #\b #\a #\a #\null #\c #\c),
but on my Sparc/Solaris box I get:
(#\a #\a #\null #\null #\null #\a #\a #\null #\null #\null)
since strcpy() stopped filling the buffer after position 1 and position 6.
What would you expect (string=? a b) to tell you? Since strings
are objects with an explicit length independent of the data, I
would expect that since the strings differ in position 3, then
string=? should return #f, but strcmp() stopped looking as soon
as it saw the nulls so we get #t. The same null dependency is precent
in STk_strcmpi() used for the case insensitive comparisons.
While R4RS does not appear to define handling of special characters,
it does not strike me as a good thing that the length should be
both explicitly recorded in the manner of Pascal and implicitely
dependent on special meanings of characters in the manner of C.
Does this need a repair? I think so. This principle difficulty lies
in fixing parts of Tk that break as a result.
Sincerely,
--
Christopher Oliver Traverse Communications
Systems Coordinator 223 Grandview Pkwy, Suite 108
oliver_at_traverse.com Traverse City, Michigan, 49684
Received on Thu Jun 01 1995 - 10:52:37 CEST