[Bug-openmcl] %get-cstring

[Gary Byers]

On Sun, 1 Feb 2004, bryan o'connor wrote:

> %get-cstring takes two &optional args to determine what part
> of the string to return.
>
> in all cases, the end was being incremented to the next null
> byte.  this was confusing callers (uffi, for example) that
> weren't requiring a null-terminated string in return.
>
> i see two fixes based on whether we want the behavior of
> %get-cstring to always return the number of bytes requested
> (if specified) or to guess that the user was looking for a
> null-terminated string.
>
> the first would look like this:
>
>    (defun %get-cstring (pointer &optional (offset 0) (end offset endp))
>      (with-macptrs ((p pointer))
>        (when (not endp)
>          (loop (if (%izerop (%get-byte pointer end))
>                    (return)
>                  (setq end (%i+ end 1)))))
>        (%str-from-ptr (%incf-ptr p offset) (%i- end offset))))
>
> the second:
>
>    (defun %get-cstring (pointer &optional (offset 0) (end offset)
> (null-terminated-p t))
>      (with-macptrs ((p pointer))
>        (when null-terminated-p
>          (loop (if (%izerop (%get-byte pointer end))
>                    (return)
>                  (setq end (%i+ end 1)))))
>        (%str-from-ptr (%incf-ptr p offset) (%i- end offset))))
>
> i prefer the former since it follows the doctrine of "give the
> user what they requested".  they're asking for a certain number
> of bytes, so only give them that many.
>
> my fear is that there is code "out there" that relies on the
> null-terminated behavior which would make the second more
> practical.
>
> 						...bryan
>

I'm not sure how much code there is that relies on either behavior;
it's only documented to take a single required argument.

There's an underlying primitive - (%STR-FROM-PTR pointer length) -
that should probably be exported.

In my mind, a C string is #\null terminated, so a function that
extracts one from memory shouldn't really take an "end" or "length"
argument; it's not clear to me that the "start" argument's that
helpful, but the argument for removing it isn't as strong.

I assume that the only reason that UFFI's calling %GET-CSTRING with an
END argument is that there's no other advertised way of getting N
bytes from memory into a string.  There should be, and %GET-CSTRING
should be left to concentrate on getting #\null-terminated strings.