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

Allow users to pass in their own byte arrays #4

Open
kevinburke opened this issue Oct 20, 2017 · 2 comments
Open

Allow users to pass in their own byte arrays #4

kevinburke opened this issue Oct 20, 2017 · 2 comments

Comments

@kevinburke
Copy link
Owner

kevinburke commented Oct 20, 2017

For example, the base64 api's have a user pass in a dst array to decode into. The nacl API's in golang.org/x/crypto follow a similar pattern.

The advantage of doing it this way is that it reduces allocations, which helps performance.

The disadvantage is that it requires the caller to know more about how the API works, and ensure they bring along a byte array that's large enough.

The C/C++ API's have it both ways. The C++ API's return a byte array, the C API's require you to pass one in, but I think the latter is because you can only return integers from C functions..

@kevinburke
Copy link
Owner Author

(To be clear, I'm not entirely convinced this is a good idea, but if anyone has input, go ahead and give it)

@raylee
Copy link

raylee commented Jun 9, 2019

Just a minor comment related to the performance issue. You can return more than just ints from a C function -- structs are fine, for example -- but how the compiler implements that is up to the platform ABI. It could be allocated from the stack which is a bit of a precious resource. So libraries in C often avoid that uncertainty and just return pointers. I wouldn't read anything more into it than that.

Anyway, thanks for this work. I'm looking forward to reading through the code.

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

No branches or pull requests

2 participants