On Mon, Jul 7, 2025 at 9:24 AM Robert Engels <reng...@ix.netcom.com> 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 what the method does. > > Eg in this case f.Name() could return a default if f is nil. > > So what is the fix here referring to? Maybe it is just an example that > requires the semantics of these api calls?
You can call the method f.Name on a nil pointer f. But in this specific case f has type *os.File, and the method (*os.File).Name will dereference f. That is the nil dereference that was incorrectly being moved later. Ian > On Jul 7, 2025, at 10:53 AM, Ian Lance Taylor <i...@golang.org> wrote: > > > On Mon, Jul 7, 2025, 8:47 AM Robert Engels <reng...@ix.netcom.com> 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 change, which is about how nil > dereference checks are handled. Previously they were moved later than they > should have been. > > Ian > > > >> On Jul 7, 2025, at 10:43 AM, 'Keith Randall' via golang-nuts >> <golang-nuts@googlegroups.com> wrote: >> >> 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 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 returned before considering >>> the error err. Doing so correctly handles I/O errors that happen after >>> reading some bytes and also both of the allowed EOF behaviors. >>> >>> Anyway: the point here is that if a function returns (ptr, err) then in the >>> case err = nil it will conventionally guarantee that ptr is valid, so the >>> caller doesn't need to check ptr != nil before dereferencing it. But if err >>> != nil, no such guarantee is implied, and it's highly unlikely that you >>> could safely deference ptr. That convention is not in the spec, but >>> dereferencing a nil pointer causing a panic is: >>> >>> the pointer indirection *x denotes the variable of type T pointed to by x. >>> If x is nil, an attempt to evaluate *x will cause a run-time panic. >>> >>> On Sunday, 6 July 2025 at 07:05:12 UTC+1 Kurtis Rader wrote: >>>> >>>> On Sat, Jul 5, 2025 at 9:19 PM Ge <everg...@gmail.com> 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 >>>>> ``` >>>>> >>>>> Where f returns a pointer and an error. f expects its callers to only use >>>>> the ptr result if the error is nil. And in particular, f returns a nil >>>>> pointer whenever it returns a non-nil error. >>>>> >>>>> This code is incorrect, in that it dereferences the ptr result before >>>>> checking the error. The Go spec says that it should nil pointer panic if >>>>> f returns a nil pointer and non-nil error. >>>>> >>>>> ``` >>>>> >>>>> I did a search in whole spec and did't find any descriptions about it. >>>>> From my understanding, `v, err := f()` is like `v1, v2 := f()` from >>>>> compiler's view, >>>>> checking error is user code's business logic and couldn't be assumed by >>>>> compiler. >>>>> If it's defined in spec, what about variants like `a, b, err := f()` or >>>>> `a, b, err1, err2 := f()`？ >>>> >>>> >>>> No, it is not defined in the spec. For the very reasons you mention (and >>>> probably others). But I would argue that commonsense suggests that unless >>>> a function explicitly says a returned non-error pointer is useful (i.e., >>>> non-nil) when an error is returned you should assume that pointer is >>>> likely to be nil if an error is indicated. Ideally this would be explicit >>>> in the documentation of every function that returns an error and non-error >>>> pointer. However, in the absence of the documentation stating that the >>>> non-error pointer value is useful if an error is indicated it seems >>>> reasonable to assume that pointer is not useful; even if it isn't nil. >>>> Even a non-pointer return value is unlikely to be meaningful if an error >>>> was indicated unless explicitly documented. If the called function returns >>>> the "zero value" when it also returns an error indicator what does it mean >>>> to ignore the error and use the "zero value"? That's obviously context >>>> dependent but it is unlikely, in my experience, to ignore the error and >>>> use the returned "zero value". >>>> >>>> -- >>>> Kurtis Rader >>>> Caretaker of the exceptional canines Junior and Hank >> >> -- >> 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 golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/61d20eb5-8102-429e-a29c-17a3da0314f3n%40googlegroups.com. >> >> -- >> 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 golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/7D77D6E6-277A-4014-8F4D-C034B3973526%40ix.netcom.com. -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVbj-BZNUtBQbXXKLTKvQAtaO-ydEnOJY2ibJFiEsxWLQ%40mail.gmail.com.
