Re: %get-cstring bug?

[bill@cambridge.apple.com (Bill St. Clair)]

>The online documentation for %get-cstring says that it takes only one
>optional argument:  offset.  However, the manual says that it takes two
>optional arguments:  offset and end.  When I call %get-cstring with a
>macptr and two more arguments, it appears to ignore the last argument and
>behave as if it had only one optional argument.  Is the 'end' optional
>argument not used?
>
>The reason I'm asking is I would like to be able to specify how much of the
>string to get (like you can do with subseq), and so having an 'end'
>argument would be nice.  Of course, I could get the whole string and then
>apply subseq to it to get the part I want, but that seems to be wasteful,
>especially if the string is very long.

%get-cstring does take an additional optional argument as specified in
the manual. The online documentation is wrong on this score. The meaning
of the additional "end" parameter is not what the manual says, however.
If "end" is specified it says where to start looking for a zero byte.
Basically, it's a way to tell %get-cstring that you know the 0 byte
is past that offset from the pointer. Exactly why the designer of
%get-cstring thought that was useful, I don't know. MCL doesn't use
it. Here's a function that will do what you want. It uses an undocumented
internal (%str-from-ptr), but since that routine has 15 callers in MCL
itself, I doubt that it will go away any time soon.

(defun %get-substring (pointer length &optional (offset 0))
  (with-pointers ((p pointer))
    (ccl::%str-from-ptr (%incf-ptr pointer offset) length)))