Need foreign string method for translate-into-foreign-memory?

[Liam Healy]

On Tue, Oct 1, 2013 at 12:35 PM, Luís Oliveira
<loliveira at common-lisp.net> wrote:
> On Tue, Oct 1, 2013 at 5:28 PM, Liam Healy <lnp at healy.washington.dc.us> wrote:
>> OK. On superficial examination, it seems like foreign-string-alloc and
>> lisp-string-to-foreign have significant duplicated code. Is there a reason
>> for that rather than having the former call the latter?
>
> Having the foreign-string-alloc call lisp-string-to-foreign would
> cause the string length to be calculated twice. But it indeed seems
> like they could both share a helper function at least.
>
> --
> Luís Oliveira

Are you sure?

;;; LMH new function
(defun length-of-string-as-foreign (string encoding start end null-terminated-p)
  (+ (funcall (octet-counter (lookup-mapping *foreign-string-mappings*
encoding))
              string start end 0)
     (if null-terminated-p
         (null-terminator-len encoding)
         0)))

;;; LMH new version
(defun foreign-string-alloc (string &key (encoding *default-foreign-encoding*)
                                      (null-terminated-p t) (start 0) end)
  "Allocate a foreign string containing Lisp string STRING.
The string must be freed with FOREIGN-STRING-FREE."
  (let* ((length
           (length-of-string-as-foreign
            string encoding start end null-terminated-p))
         (ptr (foreign-alloc :char :count length)))
    (lisp-string-to-foreign
     string ptr length :start start :end end :encoding encoding)
    (values ptr length)))

The only duplication of effort is mapping and null-len, which seem
like pretty lightweight operations. However, by adding key variables
to lisp-string-to-foreign, we could avoid the recalculation. The new
function I have defined is mostly for my clarity of thought and can be
folded into foreign-string-alloc if that's preferable.

Does this look right? What do you think?

Thanks,
Liam