-
Notifications
You must be signed in to change notification settings - Fork 33
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
Possible undefined behavior in out parameter handling #245
Comments
I started work on this in #256. I concluded that defining an OutParam type added complexity without corresponding benefit. In particular, |
Related links: https://lucumr.pocoo.org/2022/1/30/unsafe-rust/ In particular those last two made me aware of
|
Creating a reference to uninitialized memory is undefined behavior. Callers of this library are likely to pass pointers to uninitialized memory as out params. We should support that by not turning out params into references. Instead, keep them as raw pointers and use an unsafe block where we actually write the param. Fixes #245
A lot of our functions take out parameters, e.g.:
The implementation is usually like:
I think this creates undefined behavior if the caller passes a pointer to an uninitialized size_t, since we're then creating a reference to uninitialized memory. It would be better to keep out_n as a raw pointer, do the null check at the top of the function, and then dereference it in an
unsafe
block at the end of the function.Another possibility would be to define an
OutParam
wrapper type, something like:That would allow us to use the type system to ensure we've checked for null at the top. And would also allow us, on the Rust side, to clearly mark out parameters (though they are already marked rather clearly by
*mut
and occurring at the end of a function signature).The text was updated successfully, but these errors were encountered: