-
Notifications
You must be signed in to change notification settings - Fork 139
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
DV.Generic.Mutable.fill does not check for out of bounds access #118
Comments
So, I looked at this. A possible issue is that I see no way to implement a safe I'll probably split it into two functions. It's listed as an "internal" function right now, so those uses will probably transition to That's my plan, anyhow. |
I think any function which could perform unchecked out of bounds access should be marked as unsafe to make clear that they can violate memory safety. It probably make sense to expose unsafeFill as well. |
considering the type of fill is |
If it is internal function it should be given sufficiently scary name or moved into some *.Internal module. Also no one reads all that small print about which function is internal and which is not. At least I don't. |
Read the docs. It's under internal We can't help you with literacy On Monday, July 25, 2016, Aleksey Khudyakov [email protected]
|
Sorry. That was out of turn and inappropriate and mean . I let some I hope you're having a lovely afternoon and I'm excited to collaborate. On Monday, July 25, 2016, Carter Schonwald [email protected]
|
No worries. Still I think that exporting internal and public API from same module is wrong design. It's too easy to confuse then. Moreover same internal APIs contains stream/unstream & friends which are definitely part of public API since it's not possible to write fusible functions which operate on vector. So in my opinion they should be either raised to status of public API or safely hidden in some Internal module. |
Another point about public/internal API distinction: #70. Someone asked for API which would be marked internal so it makes sense to make it public. |
I guess this does nicely line up with the discussion around exposing On Tuesday, July 26, 2016, Aleksey Khudyakov [email protected]
|
Their only common point is that they about exposing/not exposing internal API. Otherwise they're largely independent. So it's probably better to discuss them separately. So we have two questions.
But this is consequence of larger problem. Representation of unboxed vectors as structure of arrays pushes borders of language expressivity. (Look at all that CPP!). Adding another instance require a lot of boilerplate and it's not possible/difficult to abstract it away. |
So it should be either renamed as unsafeFill and/or bound checks added. It's possible this is not only one function with unsafe access.
The text was updated successfully, but these errors were encountered: