Proposal: Move primitive-Data.Primitive.Addr API into base

[Carter Schonwald]

The point , hahah, of a Ptr void is that you can’t dereference it.  But you
certainly can cast it and do address arithmetic on it!!



On Mon, Oct 29, 2018 at 10:10 AM David Feuer <david.feuer at gmail.com> wrote:

> On Mon, Oct 29, 2018, 10:05 AM Sven Panne <svenpanne at gmail.com> wrote:
>
>> Am Mo., 29. Okt. 2018 um 14:27 Uhr schrieb Daniel Cartwright <
>> chessai1996 at gmail.com>:
>>
>>> 'Ptr Void' is not a pointer to a value of type 'Void'; there are no
>>> values of type 'Void': this type is nonsensical.
>>>
>>
>> That's the whole point, and it actually makes sense: If you see "Ptr
>> Void", you can't do much with it, apart from passing it around or using
>> castPtr on it. This is exactly what should be achieved by using "Ptr Void"
>> in an API. This is basically the same as "void *" in C/C++.
>>
>
> No, it does not make sense. The approximate equivalent of C's void* is Ptr
> Any. Ptr Void promises to give you anything you want on dereference, which
> is nonsense.
>
>
>> You can't store or read "()", so the same holds as for Void (which didn't
>> exist when the FFI was created IIRC).
>>
>
> Sure you can. Storing () does nothing and reading it gives (). Our () is
> somewhat similar to C's void return type.
> _______________________________________________
> 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/20181029/7e4a536f/attachment.html>