Re: expose strlen from Foreign.C.String

This is unsound: x <- malloc ... memcpy ... copy a nul-terminated string into x let len = cstringLength x free x Because GHC can float the let binding down to where it is used after free. Sent from my iPhone

On Jan 21, 2021, at 7:45 PM, Zemyla wrote:

 That doesn't sound right. I don't think it allocates any data on the heap which could cause reallocation and move an unpinned ByteArray#, which is the only way I can think it would be unsafe.

...

On Thu, Jan 21, 2021, 17:50 Andrew Martin wrote: Both the unboxed variant and the wrapper are only sound on primitive string literals. You cannot use them on anything that was allocated at runtime, only on stuff baked into the rodata section. This is a pretty onerous restriction. What use case did you have in mind?

Sent from my iPhone

...

On Jan 20, 2021, at 11:02 PM, Viktor Dukhovni wrote:



...

...

On Jan 21, 2021, at 1:39 AM, chessai wrote: On Wed, Jan 20, 2021, 17:01 Viktor Dukhovni wrote:

...

On Wed, Jan 20, 2021 at 09:54:30AM -0800, chessai wrote:

I've wanted the following before:

foreign import ccall unsafe "strlen" cstringLength# :: Addr# -> Int#

cstringLength :: CString -> Int cstringLength (Ptr s) = I# (cstringLength# s)

A natural place for this seems to be Foreign.C.String.

Why a new FFI call, rather than `cstringLength#` from ghc-prim: GHC.CString (as of GHC 9.0.1):

I forgot about that addition. In that case we would just need the lifted wrapper

No worries, sure the lifted wrapper makes sense, and Foreign.C.String does look like a reasonable place in which to define, and from which to export it.

-- Viktor.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries