Re: [go-nuts] Possible Go Compiler or Runtime bug?

On Friday, July 28, 2023 at 6:44:21 AM UTC+8 wagner riffel wrote: On 27/07/2023 03:48, Kyle Harrity wrote: > Maybe this is a known issue and or expected behavior so I thought I'd > ask here before raising an issue on github. > I think I know what's going on, the compiler inlined getStrBytes

[go-nuts] Re: error handling thoughts

The warning that I described is one presented by Visual Studio Code with the vscode-go extension. Color me stupid for having simply assumed it came from the compiler. Based on responses to this thread, I looked more closely, and found that Mr. Wagner is correct: it's coming from golint. I see t

Re: [go-nuts] error handling thoughts

On Thu, Jul 27, 2023 at 8:04 AM Steve Roth wrote: > > In those cases, what I'd like to write is > > if result, err := fn(); err != nil { > > // handle error and bail out > > } else { > > // act on result > } > > > Unfortunately, the compiler gives a warning on that. As others have pointe

Re: [go-nuts] Re: Possible Go Compiler or Runtime bug?

On Thu, Jul 27, 2023 at 3:17 PM 'Michael Knyszek' via golang-nuts wrote: > > The number 32 for the capacity comes from this constant, and the returned > byte slice in that case is likely coming from a compiler-inserted call to > stringtoslicebyte. An empty string is correctly replaced by a zero-

[go-nuts] Re: Possible Go Compiler or Runtime bug?

On Thursday, July 27, 2023 at 6:16:57 PM UTC-4 Michael Knyszek wrote: I believe this is working as intended, because I don't think the spec makes any guarantees about the capacity of the slice you get back from a conversion. (Other than the fact that the

[go-nuts] Re: Possible Go Compiler or Runtime bug?

The number 32 for the capacity comes from this constant , and the returned byte slice in that case is likely coming from a compiler-inserted call to stringtoslicebyte

Re: [go-nuts] Re: error handling thoughts

It's not a compiler error, but OP is probably referring to golint. FWIW I also prefer the `if v, err := fn(); err != nil { … }` form, in general, but in cases like these I just write v, err := fn() if err != nil { // handle error and return } // do thing with v I honestly don't see a huge pro

[go-nuts] Re: error handling thoughts

Hi Steve, What's the compiler error that you're seeing? Here's a go playground example of your scenario. It doesn't seem to cause any issues but maybe I'm misunderstanding. https://go.dev/play/p/vvtrQTl7FSr Regards, Stephen On Thursday, 27 July 2023 at 16:04:19 UTC+1 Steve Roth wrote: > The

[go-nuts] error handling thoughts

The ongoing Go survey asked a question about satisfaction with error handling in Go. I'd like to express an opinion on it that I haven't seen elsewhere, for which there was not room in the survey. I am generally a fan of the explicit error handling code in Go, but I get frustrated by the interact

[go-nuts] Types like http.Request and slog.LogValuer

I am trying to convert some older code to slog and I am running into the issue that if some data structure contains http.Request I get the message: {"time":"2023-07-27T15:49:04.744214+02:00","level":"DEBUG","msg":"req","r":"!ERROR:json: unsupported type: func() (io.ReadCloser, error)"} So I be

[go-nuts] Re: Possible Go Compiler or Runtime bug?

Interesting: https://play.golang.com/p/nSZ7tKSeot4 With the Printf commented out, it shows t has a cap of 32. With Printf uncommented, the cap drops to 0. Maybe the slice buffer is allocated on the stack in one case, and the heap on another? The slice header of 24 bytes shouldn't have anythin

[go-nuts] [security] Go 1.20.7 and Go 1.19.12 pre-announcement

Hello gophers, We plan to issue Go 1.20.7 and Go 1.19.12 during US business hours on Tuesday, August 1. These minor releases include PRIVATE security fixes to the standard library, covering the following CVE: - CVE-2023-29409 Following our security policy, this is the pre-announcement o

[go-nuts] Re: Possible Go Compiler or Runtime bug?

That looks very weird. The panic is triggered if I uncomment line 17 (the final fmt.Printf) even though it never reaches there - it panics when getStrBytes is called from line 9 (in line 23). On Thursday, 27 July 2023 at 13:12:40 UTC+1 Kyle Harrity wrote: > I first asked this on https://reddit.

[go-nuts] Possible Go Compiler or Runtime bug?

I first asked this on https://reddit.com/r/golang but the contribution guide on github recommends this forum, so I'll post here before finally raising an issue on github if this appears to be a real bug. ORIGINAL POST: I came across this issue in some code I was reviewing today where a string