News for hackers. Stuff that matters.
Re:Down the Golang Nil Rabbit Hole by TheDong on Tuesday March 30, 2021 @01:22AM (#26631466)
One of them has to be the for loop reusing value thing.

    func processItem(item *string) {
      if item == nil {
        fmt.Println("nil item")
        return
      }
      fmt.Println(*item)
    }
    
    stuffToProcess := []string{"one", "two"}
    wg := sync.WaitGroup{}
    for _, item := range stuffToProcess {
      wg.Add(1)
      go func(s *string) {
        time.Sleep(1 * time.Millisecond)
        processItem(s)
        wg.Done()
      }(&item)
    }
    wg.Wait()
    // What do I print?
Playground here: https://play.golang.org/p/mouvT1BkpNJ
Re:Down the Golang Nil Rabbit Hole by zimpenfish on Tuesday March 30, 2021 @03:17AM (#26631960)
gosec[1] will warn you about this, at least.

    [reuse.go:26] - G601 (CWE-118): Implicit memory aliasing in for loop. (Confidence: MEDIUM, Severity: MEDIUM)
    25:    wg.Done()
  > 26:   }(&item)
    27:  }
[1] https://github.com/securego/gosec
Re:Down the Golang Nil Rabbit Hole by JulianMorrison on Tuesday March 30, 2021 @06:33PM (#26641399)
Easily enough fixed by item := item (that is, shadow the variable with something new that won't be overwritten)
Re:Down the Golang Nil Rabbit Hole by mimischi on Tuesday March 30, 2021 @02:41AM (#26631766)
Can‘t this be fixed by changing bits to be passed by value?

https://play.golang.org/p/srAyKZN2NTH

Re:Down the Golang Nil Rabbit Hole by thwarted on Tuesday March 30, 2021 @02:55AM (#26631836)
Yes, it is odd to pass the address of a local variable from the enclosing scope like this to a go routine.
Re:Down the Golang Nil Rabbit Hole by masklinn on Tuesday March 30, 2021 @03:52AM (#26632139)
Well that's true in the sense that usually you'd just close over it, which is the classic broken case of closing over a mutable binding: https://play.golang.org/p/40FRmvhifBl

I assume GGP's contrived example is to show the underlying mechanics of the issue.