(Context actually mostly irrelevant; what's important is the lack of explicit length/cap on the slice.)
What did you expect to see?
checkptr thinking i totally know what i'm doing, or telling me what's wrong
What did you see instead?
"unsafe pointer conversion"
I mentioned this in passing because I thought it was complaining that we couldn't prove that the pointer was aligned, but bcmills pointed me at the CL for having checkptr not complain about unaligned access when it's to non-pointer-typed data. Another user (hi kale!) pointed out a more subtle issue: https://go-review.googlesource.com/c/sys/+/225418
It turns out checkptr also complains about slices which lack a length/capacity. That's completely reasonable, but I didn't know it was one of the rules checkptr would enforce, and the diagnostic didn't say what it was doing.
Suggestion: checkptr diagnostics should be distinct, and say things like "potential misalignment", or "slice without length or capacity" or something else that would make it more immediately obvious what it's complaining about.
(It's right, though.)
The text was updated successfully, but these errors were encountered:
I think what I'm mostly advocating for is "at the point of deciding to report a thing, flag in some way the basis for the decision". That message would probably have communicated the issue to me (although I might have mistaken it for alignment anyway). So, the specific thing of saying that len/cap is needed might be overkill, but something like "converted pointer points to 8192 bytes, base pointer is 2048 bytes before end of allocation" might be helpful too. But mostly, things like distinguishing between "this looks to be looking outside the object the pointer was derived from" and "this is unaligned" and whatnot seem like they'd be useful. In this case, i happen to know that c.array() is a uint16 of length n, and if i use [:n:n] in the slice, it works fine and checkptr doesn't fuss. but since i know that it's a length n slice of uint16, it didn't occur to me to worry about the theoretical bounds of the slice, until someone pointed it out.
I think what I'm mostly advocating for is "at the point of deciding to report a thing, flag in some way the basis for the decision".
Okay. I believe that's what 1f231d7 does. After that CL, checkptr reports unique error messages for each case it checks.
something like "converted pointer points to 8192 bytes, base pointer is 2048 bytes before end of allocation" might be helpful too.
We don't always know the "N bytes before end of allocation" part (e.g., the base pointer might be to a statically-allocated, package-level Go variable, or it might be into C memory), but we could certainly include additional details like that when we do know them.
I think we can simplify the wording though. E.g., maybe something like:
checkptr: converted pointer straddles multiple allocations (points to 2048-byte allocation, but uint16 is 131072 bytes)
Open to suggestions though.
changed the title
cmd/compile: -d=checkptr should say what rule it thinks you're breakingAug 7, 2020
I think this is a case where more information is almost always better, and any additional insight into the violation will be valuable to the user.
Say I have b byte, and I obtain a poiter to &b, and cast it to *byte. That's the case where the wording seems hard to me; "points to 16-byte allocation, but byte is 65536 bytes" would be slightly confusing.