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

Use Number instead of Int for read #25

Closed
matthewleon opened this issue Nov 6, 2017 · 3 comments · Fixed by #35
Closed

Use Number instead of Int for read #25

matthewleon opened this issue Nov 6, 2017 · 3 comments · Fixed by #35

Comments

@matthewleon
Copy link
Contributor

matthewleon commented Nov 6, 2017

I've made a branch here to show this in a test: https://github.com/matthewleon/purescript-node-buffer/tree/uint32-test

Relevant code:

testUInt32 :: Test
testUInt32 = do
  buf <- fromArray [-1, -1, -1, -1]
  readVal <- read UInt32LE 0 buf
  logShow readVal -- 4294967295
  logShow $ readVal - 1 -- -2
  -- chaos reigns: try to uncomment the line below
  --logShow $ readVal == 4294967295

Purescript Ints really don't play nice with these operations. They probably require something like https://github.com/zaquest/purescript-uint

@hdgarrood
Copy link
Member

Yes, we should have these functions use a UInt type. I'd rather it be in contrib if we're going to depend on it in this library, though.

@matthewleon
Copy link
Contributor Author

Makes sense. I'd be happy to see it make its way into contrib.

@hdgarrood
Copy link
Member

Come to think of it, we really ought to be using Number as the return type of read, since you can read a Double{BE,LE} or a Float{BE,LE} out of a Buffer, and clearly any integer type is unsuitable for that. Using Number as the return type addresses the UInt32 issue too. Since these libraries are meant to be low-level bindings, I think the loss of convenience is acceptable.

@hdgarrood hdgarrood changed the title UInt32 operations: chaos reigns Use Number instead of Int for read Jan 13, 2019
hdgarrood added a commit that referenced this issue Mar 10, 2019
Int is not suitable for many of the options for BufferValueType, since
both UInt32 types as well as all of the floating point types are
inhabited by values which are not representable as Int.

This is quite a big breaking change unfortunately, but the library is
basically broken for about half of the BufferValueType constructors
right now, and this seems to me to be the most sensible way of fixing
it.

Note that {to,from}Array are unchanged because they deal with arrays of
octets.
hdgarrood added a commit that referenced this issue Jun 30, 2019
Use Number for reading and writing, fixes #25
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 a pull request may close this issue.

2 participants