infosec enthusiast • Go dev & trainer • contributor to the Go project • minimalist • chaotic good • trying to make sense of the Web • he/him
Blog: https://jub0bs.com
Free Go course: https://github.com/jub0bs/go-course-beginner
Free 🇵🇸! Leave 🇱🇧 alone!
jub0bs
Loading...
Paradoxically (perhaps), as the Go compiler becomes better at eliminating bounds checks, attacker-reachable panics due to incorrect programmer assumptions about indices become easier to find.
#golang
Fewer bounds checks in #golang thanks to Youlin Feng: go-review.googlesource.com/c/go/+/719881
Even when you cannot eliminate all bounds checks within a loop, eliminating most of them may benefit performance. 😉
#golang
go-review.googlesource.com/c/go/+/759100
When something tantalising gets merged at tip, you can put code that relies on it in a file guarded by a //go:build go1.27 build constraint and its pre-1.27 counterpart in a file guarded by a //go:build !go1.27 build constraint. No need to update your go.mod's go directive.
Unfortunately, this proposal would require a breaking change. Therefore, I've decided to retract it.
I love how the conjunction of #golang's modules system and build constraints lets you have your cake and eat it too! 🍰
You can let users of your library take advantage of the bleeding edge if they so wish without cutting off one of the currently supported Go toolchains.
#golang quiz: What happens if you try to compile and run the following program?
package main
import (
"fmt"
"math"
)
func main() {
fmt.Println(int(math.NaN()))
}
a. It prints 0.
b. It prints -1.
c. It panics.
d. Compilation fails.
e. Something else.
I've just filed a proposal to make bool an ordered type (compatible with operators <, <=, >, and >=) in #golang: github.com/golang/go/is...
Find out how the source-level inliner in Go 1.26 can help you with API migrations.
go.dev/blog/inliner
