On Wednesday, June 4, 2025 at 3:59:20 AM UTC+8 Axel Wagner wrote:
They can just define a singleton sentinel of the error type. e.g. do
type errValue struct{}
func (e *errValue) Error() string { return "…" }
var valueErr = new(errValue)
if errors.Is(err, valueErr) { … }
No need to define new API, if this can just be solved by fixing the code.
Perhaps there should be a vet check (either for comparisons of pointers to
zero-sized values, or specifically for pointers to zero-sized error types).
Or better, use ErrType instead of *ErrType, so that no need to declare the
global error var.
On Tue, 3 Jun 2025 at 17:56, [email protected] <[email protected]> wrote:
On Tuesday, June 3, 2025 at 8:58:10 PM UTC+8 Bushnell, Thomas wrote:
Why do you think these are incorrect uses of errors.Is? If you are only
testing the Boolean value, Is is fine and the same as As; you should only
use As if you are actually going to use the identified error value in some
way.
Because errors.Is mainly use == to compare errors. When the errors are
pointers to zero-size values, the comparison result is compiler dependent,
as the whole thread is talking about.
Maybe using errors.As is also not a good idea for such cases. Such cases
just need an errors.OfType[ErrType]() alike function.
*From:* [email protected] <[email protected]> *On Behalf Of
*[email protected]
*Sent:* Monday, June 2, 2025 3:14 PM
*To:* golang-nuts <[email protected]>
*Subject:* Re: [go-nuts] Comparison of pointers to distinct zero-sized
variables
This message was sent by an external party.
On Sunday, June 1, 2025 at 11:21:28 PM UTC+8 Oliver Eikemeier wrote:
> Am 27.06.2024 um 05:17 schrieb Ian Lance Taylor <[email protected]>:
>
> On Tue, Jun 25, 2024 at 9:37 PM 'Axel Wagner' via golang-nuts
> <[email protected]> wrote:
>>
>> you might be interested to learn that Ian has filed a CL adding an FAQ
entry.
>
> Now committed at https://go.dev/doc/faq#zero_size_types .
>
> Ian
Thanks for that. I discovered that comparing pointers to ZSTs is pretty
popular in Go:
- x/sync/singleflight:
https://cs.opensource.google/go/x/sync/+/refs/tags/v0.14.0:singleflight/singleflight_test.go;l=78
- Delve:
https://github.com/go-delve/delve/blob/v1.24.2/service/debugger/debugger.go#L387
- Grafana:
https://github.com/grafana/grafana/blob/v12.0.1/pkg/services/serviceaccounts/extsvcaccounts/service.go#L353
- Skaffold:
https://github.com/GoogleContainerTools/skaffold/blob/v2.16.0/pkg/skaffold/hooks/render.go#L93
- Coder: https://github.com/coder/coder/blob/v2.22.1/cli/ssh.go#L578
- quic-go:
https://github.com/quic-go/quic-go/blob/v0.52.0/connection_test.go#L1008
- SigStore Cosign:
https://github.com/sigstore/cosign/blob/v2.5.0/cmd/cosign/cli/attest/attest_blob_test.go#L60
Seems like a classic example of Hyrum's Law, we now have a lot of code that
depends on runtime.zerobase.
It looks all of bad code (using errors.Is) should use errors.As instead.
This indeed reflects that the design of the errors APIs is prone to being
misused.
An "errros/v2" is really needed to avoid such misuses.
I’ve written a linter along with an accompanying blog post about the
subject:
fillmore-labs.com/zerolint: https://github.com/fillmore-labs/zerolint
“The Perils of Pointers in the Land of the Zero-Sized Type”:
https://blog.fillmore-labs.com/posts/zerosized-1/
I would be interested whether I got the “default” level right. Or maybe
everything wrong.
Thanks for the insight, again
Oliver
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/7750b85c-2e09-4e42-a290-480b81caf19dn%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/7750b85c-2e09-4e42-a290-480b81caf19dn%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/06eef021-6d5b-496c-898f-bdd375453b35n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/06eef021-6d5b-496c-898f-bdd375453b35n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/d9b53c59-1d53-49bc-98e0-5d0b587b5705n%40googlegroups.com.
