Thanks for your answer!
>>...If not enough destlen, error
> This is completely Unlispy IMHO. Yon shouldn't bother the user with such
> If you want to proceed, you ought to estimate the length for the result.
> The manual page for compress2() gives an estimate: len * 1.001 + 12.
> Alternatively, the module already exports the function compress-bound.
This for compress operation, not for uncompress. I do not know how
calculate buffer size for uncompress.
> Still, I'm not convinced that compress-string is needed.
May be. I do not insist. I have written function "compress-string" for
use cl-pdf without any other interfaces to zlib library.
> If you still want to proceed, I recommend you do some performance
> measurements against a function using WITH-FOREIGN-STRING instead of
> wasting an array via CONVERT-STRING-TO-BYTES.
> But for that, you'll need a second FFI definition for compress2, because
> the current one expects an (C-ARRAY-PTR uint8), while the other needs a
There is no opportunity to coerce FOREIGN-ADDRESS to (C-ARRAY-PTR uint8)?
(for reuse #compress from zlib and not define second FFI definition for
> Argh, but that's the FFI.
Very nice interface :)
> As for the proposed default of custom:*misc-encoding*, why not require
> an encoding instead of default to some debatable choice?
> Note that IMHO, defaulting to *foreign-encoding* is as debatable as
I do not insist on the version.
> A required parameter would
> 1) be consistent with convert-string-to/from-bytes
> 2) prevent obscure bugs introduced by the "defaulting hell". People are
> not aware or forget that some extra argument exist (which happens no
> later than the next API laid atop that API (say by e.g. UFFI, cl-pdf or
> And I find uncompress-string somewhat misleading. Maybe
> uncompress-to-string or uncompress-bytes-to-string? The latter would be
> somehow in-line with EXT:CONVERT-STRING-TO/FROM-BYTES, even though the
> opposite word ordering is confusing.
> The only benefit providing of(un)compress-string(-from-bytes) might be
> that it would prevent people from writing least optimal solutions (in
> terms of performance). But if we constantly need to be weary of least
> optimal solutions, we should rather query whether we have the right
> primitives to start with.
I agree: (un)compress-string(-to/-from)-bytes is better
> Jorg Hohle.
Many thanks again.
WBR, Yaroslav Kavenchuk.