Strict byteArray of IV c#16
Merged
Merged
Conversation
This provides a way to seq `IV c` and its content when client wants to prevent thunk exploding, It's not rare to apply multiple `ivAdd` on single `IV c` and we often don't want thunk here.
kazu-yamamoto
approved these changes
Sep 16, 2023
Owner
kazu-yamamoto
left a comment
kazu-yamamoto
left a comment
There was a problem hiding this comment.
I think this is a good start.
Owner
|
General comment. Even with |
Owner
|
Merged. |
Author
|
I'm okay with the current version (with simple workaround) so feel free to release new version when you think it's ready. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This provides a way to seq
IV cand its content when client wants to prevent thunk exploding, It's not rare to apply multipleivAddon singleIV cand we often don't want thunk here.About the idea, "using
StrictData", in our previous discussion, I found that was a very time-consuming job to do if we want to make sure everything still works after change.Take
Pointfor instancecrypton/Crypto/ECC/Simple/Types.hs
Line 105 in 50792f1
it has instance of
NFDatabut itsInteger(x and y) field was not marked as strict, which is difficult be to certain that all its user/algorithm never requires these fields to be lazy. And we have more than one type like this.To reduce the impact, I'll vote for only changing the part I knew that has issue (thunk) and have confidence in solving it in a safer way.