CC @mdempsky

Go 1.15 will improve the error message somewhat: 1f231d7. (Your case will now report "converted pointer straddles multiple allocations".)

Does that address your concerns, or are you suggesting that checkptr should specifically recognize (*[big]T)(p)[:] and hint the user should add len/cap to the slice?

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 [65536]uint16 is 131072 bytes)

Open to suggestions though.

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 [65536]byte, and I obtain a poiter to &b[65530], and cast it to *[16]byte. That's the case where the wording seems hard to me; "points to 16-byte allocation, but [65536]byte is 65536 bytes" would be slightly confusing.

Say I have b [65536]byte, and I obtain a poiter to &b[65530], and cast it to *[16]byte.

In this case, my proposed wording would be: points to 6-byte allocation, but [16]byte is 16 bytes.

Can we do points to byte offset 65530 in a 65536-byte allocation, but [16]byte is 16 bytes.
(Including the offset only if it is nonzero.)

Yeah that seems doable.