-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
RFC: zero initializer / undefined intrinsics for POD types #3471
Comments
Here is an example that came up on IRC, but it comes up regularly: http://pastebin.com/v534PrDW. Sscroll to the final function. |
In C++, POD structs can contain pointers. |
SpiderMonkey contains a similar https://bugzilla.mozilla.org/show_bug.cgi?id=551276 |
I'd prefer to declare the C function as taking a |
Yeah, I wrote "more-or-less" because I figured |
So, it turns out that this exists! (the intrinsic |
Oh, never mind, |
Closed by #6354 |
threads: keep track of why we are blocked, and sanity-check that when waking up Also remove support for condvars blocked on rwlocks, as that was no longer used.
Perhaps we should add an intrinsic like:
that basically fills
T
with zeros. This is perfectly safe for POD types. Of course, we don't have a POD kind yet, but that's a separate issue I guess. This is particularly useful in C interop, where you often have functions with out-params that otherwise need to be initialized by hand.We could also add an intrinsic like
which would just leave the data uninitialized. This would be more efficient but less safe in some sense. Though restricting it to POD at least preserves memory safety, more-or-less.
The idea is you'd write something like:
The text was updated successfully, but these errors were encountered: