Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate memcpy and memset #591

Merged
merged 3 commits into from
Jun 11, 2023
Merged

Conversation

clyring
Copy link
Member

@clyring clyring commented Jun 5, 2023

Starting with ghc-9.8, copyBytes and fillBytes from base will use dedicated primops that ghc can sometimes emit better code for if the length is known and small enough. We should take advantage of this rather than using a foreign call that ghc won't recognize.

See also https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9629

Starting with ghc-9.8, copyBytes and fillBytes from base will use
dedicated primops that ghc can sometimes emit better code for if the
length is known and small enough.  We should take advantage of this
rather than using a foreign call that ghc won't recognize.

See also https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9629
@@ -1019,27 +1020,22 @@ memcmp p q s = c_memcmp p q (fromIntegral s)
foreign import ccall unsafe "string.h memcpy" c_memcpy
:: Ptr Word8 -> Ptr Word8 -> CSize -> IO (Ptr Word8)

{-# DEPRECATED memcpy "Use Foreign.Marshal.Utils.copyBytes instead" #-}
-- | deprecated since @bytestring-0.11.5.0@
memcpy :: Ptr Word8 -> Ptr Word8 -> Int -> IO ()
memcpy p q s = void $ c_memcpy p q (fromIntegral s)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we actually implement it via copyBytes and scrap foreign import?

@Bodigrim Bodigrim added this to the 0.11.5.0 milestone Jun 11, 2023
@Bodigrim Bodigrim merged commit aa79cf8 into haskell:master Jun 11, 2023
clyring added a commit that referenced this pull request Jun 13, 2023
* Deprecate memcpy and memset

Starting with ghc-9.8, copyBytes and fillBytes from base will use
dedicated primops that ghc can sometimes emit better code for if the
length is known and small enough.  We should take advantage of this
rather than using a foreign call that ghc won't recognize.

See also https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9629

* clean up some fromIntegral calls

* remove foreign import for memcpy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants