-
Notifications
You must be signed in to change notification settings - Fork 326
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
Fix error message for direct pointer access #541
Comments
Please can I have a bit more code context? I'm not confident I know the exact issue. |
|
I see.
Actually this is a conscious design decision as nearly all (if not all?) parameter arrays have a known upper bound, and this forces you to specify it. Without the slice step, it's far easier to accidentally buffer overrun / underrun. By removing raw pointer offsets I caught quite a few issues with this in early development of GAPID. Does the extra slice step really hurt? @AWoloszyn, any thoughts on this? |
It does not hurt that much, but I find it odd - at the very least the error message is odd. |
Agreed. I'm more than happy to fix that. |
I do prefer the explicitly sized slices for things. |
As discussed in google#541, we were intentionally forcing the developer to go via a slice, but TexParameter!T would be horrible to implement with this constraint in place as T can be a static array or slice. Fixes google#541
ptr[1] = .... fails with "type u64 not valid slicing pointer"
We generally work around the bug by slicing the pointer first.
The text was updated successfully, but these errors were encountered: