expose strlen from Foreign.C.String

[Andrew Martin]

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 <zemyla at gmail.com> 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 <andrew.thaddeus at gmail.com> 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 <ietf-dane at dukhovni.org> wrote:
>> > 
>> > 
>> >> 
>> >>> On Jan 21, 2021, at 1:39 AM, chessai <chessai1996 at gmail.com> wrote:
>> >>> On Wed, Jan 20, 2021, 17:01 Viktor Dukhovni <ietf-dane at dukhovni.org> 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 at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210122/fd32947d/attachment.html>