Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/tls: On a failed call to tls.Dial the returned net.Conn evaluates to false on comparison of net.Conn == nil, but prints <nil> when printing the value #24835

Closed
raz-varren opened this issue Apr 12, 2018 · 4 comments

Comments

@raz-varren
Copy link

@raz-varren raz-varren commented Apr 12, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

I've reproduced the error on go 1.10.1 linux and 1.9.2 darwin

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

I've produced the error on my mac:
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/russell/gocode"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/d3/kzyj6l8s5j3fz4848dls2tjw0000gn/T/go-build303409938=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

and on my linux docker container:
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/opt/gt/gocode"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build289060333=/tmp/go-build -gno-record-gcc-switches"

What did you do?

During a failed call to tls.Dial, the returned net.Conn fails to evaluate to true in a comparison of net.Conn == nil.
The error is reproducible here: https://play.golang.org/p/KlpsoDFmEnf

What did you expect to see?

If an error occurs during a call to tls.Dial, the returned net.Conn should evaluate to true in a comparison of net.Conn == nil

What did you see instead?

net.Conn == nil evaluates to false, even though fmt.Println(net.Conn) will print <nil>

@raz-varren raz-varren changed the title On a failed call to tls.Dial the returned net.Conn evaluates to false on comparison of net.Conn == nil, but prints <nil> when printing the value crypto/tls: On a failed call to tls.Dial the returned net.Conn evaluates to false on comparison of net.Conn == nil, but prints <nil> when printing the value Apr 12, 2018
@AlexRouSg

This comment has been minimized.

Copy link
Contributor

@AlexRouSg AlexRouSg commented Apr 13, 2018

Simplified repo:

package main

import (
	"fmt"
)

type foo struct{}
type bar interface{}

func main() {
	var f *foo = nil
	var b bar = f

	fmt.Println(b)
	fmt.Println(b == nil)
}
@pam4

This comment has been minimized.

Copy link

@pam4 pam4 commented Apr 13, 2018

I think the faq explains it nicely here
tls.Dial is returning a nil *tls.Conn (pointer to struct), and you are assigning it to a variable of interface type (net.Conn), that will therefore be non-nil even if the pointer inside is nil.
Then fmt.Print* uses a type switch or reflect to get the dynamic value, and it discovers a nil pointer and prints <nil>.

@agnivade

This comment has been minimized.

Copy link
Contributor

@agnivade agnivade commented Apr 13, 2018

That's right. You are assigning a *tls.Conn to net.Conn. So the underlying type will always be non-nil. Either do a type assertion to get the underlying type, or do not assign to an interface.

Closing this as "not a bug".

@raz-varren

This comment has been minimized.

Copy link
Author

@raz-varren raz-varren commented Apr 13, 2018

Ah, I see. That makes perfect sense now. Thank you.

@golang golang locked and limited conversation to collaborators Apr 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.