Adding `NonNullPtr` to Foreign.Ptr

[Kleidukos]

Hello CLC :)

I would like to propose an addition to the Foreign data types: NonNullPtr.

Rationale

Just like NonEmpty, I need to express and enforce certain properties of my pointers in FFI.
While looking for such a thing on Hackage Search, I found @sergv's implementation, which he authorised me to submit for upstreaming to base.

Implementation

This would be a newtype wrapper in the form of:

newtype NonNullPtr a = NonNullPtr (Ptr a)
  deriving (a bunch of instances)

With the constructor not exported.

with the following API:

nonNull :: forall a. Ptr a -> Maybe (NonNullPtr a)

getNonNull :: forall (a :: Type). NonNullPtr a -> Ptr a

castPtr :: forall a b. NonNullPtr a -> NonNullPtr b

movePtr :: forall a b. NonNullPtr a -> Int -> NonNullPtr b 

diffPtr :: forall a b. NonNullPtr a -> NonNullPtr b -> Int

alignPtr :: forall a. NonNullPtr a -> Word -> NonNullPtr a 

alloca :: forall a b. Storable a => (NonNullPtr a -> IO b) -> IO b

allocaBytes :: forall a b. Word -> (NonNullPtr a -> IO b) -> IO b

allocaBytesAligned :: forall a b. Word -> Word -> (NonNullPtr a -> IO b) -> IO b

Due to name clashes, it would have to live in its own module: Foreign.NonNullPtr. Qualified import would be heavily suggested in the documentation.

Breakage

From a search on Hackage and GitHub, only emacs-module seems to implement such a thing. I do not expect much direct breakage from this addition.

Discussion

Making sure the pointer is always non null

I'm taking suggestions on that one. I'm not uncomfortable with drawing boundaries (after all, GHC is not a proof assistant), but if anyone's ever had to maintain that kind of invariant throughout a program, I am all ears for experience feedback.

emacs-module for instance has an ASSERTIONS CPP flag that would provoke an exception if the pointer is shown to be null at run-time (https://github.com/sergv/emacs-module/blob/master/src/Data/Emacs/Module/NonNullPtr.hs#L29). This technique is most commonly found in C, although Haskell has a preference for returning Maybe types.

On the C (:ocean:) side, the ARM toolchain manual reports:

__attribute__((nonnull)) function attribute
This function attribute specifies function parameters that are not supposed to be null pointers. This enables the compiler to generate a warning on encountering such a parameter.

ARM Compiler toolchain Compiler Reference Version 5.03

[treeowl]

Do your alloca variants just throw errors if given non-positive inputs? Are you considering a ForeignPtr-like type with a malloc?

[Kleidukos]

@treeowl So, that is a point of discussion: exceptions or Maybe. I'm certainly open for feedback on this.

Regarding the ForeignPtr that is just an oversight which I will correct.

[kozross]

__attribute__((nonnull)) is far broader than the ARM compiler: both GCC and Clang have it in some form. It is also technically possible even in vanilla C by using something like

int foo (int bar[1]) {
...

For the alloca variants that take a size, we should just accept that Int was a bad type for this and use either Word or CSize or something.

[treeowl]

I would definitely lean towards exceptions, but that's just my intuition. If we had Dependent Haskell I think the choice would be easier.

I'm a bit unclear on how plusPtr fits in. How can you guarantee the result isn't null? And even if it isn't, there's no guarantee it's memory the program can access, let alone memory intended for this purpose.

[Kleidukos]

@treeowl yeah good enough reason for me not to include it :)

[kozross]

For what it's worth, plusPtr on regular Ptrs can't make guarantees about accessible or 'intended for purpose' memory, whatever that last part is. I'm unsure if C permits pointer arithmetic to lead to NULL off the top.

[sergv]

The idea of my implementation was that NonNullPtr can be created from vanilla Ptr by checking non-nullness but functions like alloca can be implemented as a safe cast of Foreign.Marshal.Alloc.alloca because they always return non-null pointer and thus there's no need for assertions at runtime. Therefore API can be meanigfully used without ever checking whether pointer is null at runtime.

[treeowl]

For what it's worth, plusPtr on regular Ptrs can't make guarantees about accessible or 'intended for purpose' memory, whatever that last part is. I'm unsure if C permits pointer arithmetic to lead to NULL off the top.

I haven't checked, but I would be shocked if the C standard offered any guarantee that pointer arithmetic from a non-NULL pointer cannot lead to NULL. I would not be at all surprised if there were no way to produce a guaranteed NULL result from such arithmetic.

[hasufell]

This is a useful discussion. But it's also proof to me that there's a design space to explore and that exploration shouldn't happen in base.

[Bodigrim]

Once you get your design into base, it would be extremely difficult to iterate and respond to feedback. And any usage of the new interface will be limited to GHC 9.8+ only. For now you'd be much happier doing this outside of base, in a standalone library.

[Bodigrim]

@Kleidukos how would you like to proceed?

[Kleidukos]

From this discussion I believe that it would be more reasonable to create a library and see what can be achieved before upstreaming it.

My thanks to everyone who participated in this discussion. :)