Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Mon, Jul 7, 2025 at 9:24 AM Robert Engels wrote: > >  > It seems I clearly don’t understand it - based on the example in the > documentation for the 1.25 compiler changes - why would this gave to panic? > You can call methods on nil pointers - so this call is valid - it all depends > on wha

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

Or maybe it is how the proposed solution is worded. “ If this change is affecting your code, the solution is to put the non-nil error check earlier in your code, preferably immediately after the error-generating statement.”This is only the case if the api call does not return valid results in addit

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

It seems I clearly don’t understand it - based on the example in the documentation for the 1.25 compiler changes - why would this gave to panic? You can call methods on nil pointers - so this call is valid - it all depends on what the method does. Eg in this case f.Name() could return a default if

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Monday, July 7, 2025 at 8:48:03 AM UTC-7 Robert Engels wrote: This change seems wrong just based on the io.Reader returns of valid bytes and an error. I'm not sure what you are saying. This change (CL 657715) is just about doing (pointer) nil checks where the spec says they should go. The

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Mon, Jul 7, 2025, 8:47 AM Robert Engels wrote: > This change seems wrong just based on the io.Reader returns of valid bytes > and an error. An error doesn’t always mean the other return values are > invalid - it is decided by the api method. > I think you are misunderstanding the actual chang

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

This change seems wrong just based on the io.Reader returns of valid bytes and an error. An error doesn’t always mean the other return values are invalid - it is decided by the api method. On Jul 7, 2025, at 10:43 AM, 'Keith Randall' via golang-nuts wrote:See the second paragraph in the compiler

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

See the second paragraph in the compiler section of the go1.25 release notes: https://tip.golang.org/doc/go1.25#compiler The example looks strangely familiar... On Sunday, July 6, 2025 at 1:18:20 AM UTC-7 Brian Candler wrote: > The main example which springs to mind is io.Reader.Read >

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

The main example which springs to mind is io.Reader.Read which may return a non-zero number of read bytes *and* and error from the same call. Because this is so unusual, it is carefully emphasised in the docs: *Callers should always process the n > 0 bytes returne

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Sat, Jul 5, 2025 at 9:19 PM Ge wrote: > Thanks Ian and Dominik for the tips. I have checked the issue 72860 and > found randall77 posted a comment that > I couldn't confirm from golang spec(go.dev/ref/spec): > > //https://github.com/golang/go/issues/72860#issuecomment-2734549770 > ``` > > Wher

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Sat, Jul 5, 2025 at 9:19 PM Ge wrote: > > Thanks Ian and Dominik for the tips. I have checked the issue 72860 and found > randall77 posted a comment that > I couldn't confirm from golang spec(go.dev/ref/spec): > > //https://github.com/golang/go/issues/72860#issuecomment-2734549770 > ``` > > Wh

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

Thanks Ian and Dominik for the tips. I have checked the issue 72860 and found randall77 posted a comment that I couldn't confirm from golang spec(go.dev/ref/spec): //https://github.com/golang/go/issues/72860#issuecomment-2734549770 ``` Where f returns a pointer and an error. f expects its caller

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

Memory beats git bisect, but this was indeed fixed by a1ddbdd3ef8b739aab53f20d6ed0a61c3474cf12. On Saturday, July 5, 2025 at 6:36:57 PM UTC+2 Ian Lance Taylor wrote: > On Sat, Jul 5, 2025 at 8:24 AM Ge wrote: > > > > As follows showing, when `-N` is enabled with compiler, it gives the > expect

Re: [go-nuts] Go compiler changes code behaviour with optimization enabled

On Sat, Jul 5, 2025 at 8:24 AM Ge wrote: > > As follows showing, when `-N` is enabled with compiler, it gives the > expected output. > ``` > ➜ grd more nf2.go > package main > > import "os" > > func main() { > f, err := os.Open("nonExistFile") > fname := f.Name() > if er

[go-nuts] Go compiler changes code behaviour with optimization enabled

As follows showing, when `-N` is enabled with compiler, it gives the expected output. ``` ➜ grd more nf2.go package main import "os" func main() { f, err := os.Open("nonExistFile") fname := f.Name() if err != nil { println("failed to open file, Error:",