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

unsafe.Sizeof() behaves incorrectly in global declaration #1608

Closed
gopherbot opened this issue Mar 15, 2011 · 6 comments
Closed

unsafe.Sizeof() behaves incorrectly in global declaration #1608

gopherbot opened this issue Mar 15, 2011 · 6 comments

Comments

@gopherbot
Copy link
Contributor

by eleanor@games-with-brains.com:

What steps will reproduce the problem?
    import "unsafe"

    var _a interface{} = 0
    size := unsafe.Sizeof(_a)

What is the expected output?
    The size should be reported as a number of bytes equal to two native pointers.

What do you see instead?
    The size is reported as -1000000000 bytes.

Which compiler are you using (5g, 6g, 8g, gccgo)?
    6g

Which operating system are you using?
    Darwin AMD64

Which revision are you using?  (hg identify)
    c5c62aeb6267 release.2011-03-07.1/release

Please provide any additional information below.
@dchest
Copy link
Contributor

dchest commented Mar 15, 2011

Comment 1:

c5c62aeb6267+ release/release.2011-03-07.1
Mac OS X 10.6.6 Build 10J567, darwin-amd64
Size is reported as 16 for me.
Program:
package main
import 
( 
    "unsafe"
    "fmt" 
)
func main() {
    var _a interface{} = 0
    size := unsafe.Sizeof(_a)
    fmt.Println(size)
}

@gopherbot
Copy link
Contributor Author

Comment 2 by eleanor@games-with-brains.com:

When I run that program the size is reported correctly, and also if I declare _a as a
package-level variable (which is how it's being used in my code).
For me the problem manifests itself when I'm running tests via gotest (which I should
have mentioned in my original report - apologies about that, it's such an ingrained part
of my workflow that I tend to forget I'm using it).
runtime.go
=======
    package raw
    import "unsafe"
    type BasicType struct {
        size                int
        alignment       int
    }
    var _a interface{} = 0
    var INTERFACE = BasicType{ unsafe.Sizeof(_a), unsafe.Alignof(_a) }
test_runtime.go
==========
    package raw
    import "testing"
    import "unsafe"
    var _b interface{} = 0
    var _i = BasicType{ unsafe.Sizeof(_b), unsafe.Alignof(_b) }
    func TestInterfaceSize(t *testing.T) {
        t.Logf("_b size = %v, align = %v", unsafe.Sizeof(_b), unsafe.Alignof(_b))
        t.Logf("_i.size = %v, align = %v", _i.size, _i.alignment)
    }
output
====
    _b size = 16, align = 8
    _i.size = -1000000000, align = 8
I would have expected unsafe.Sizeof(_b) and _i.size to be the same, and likewise
unsafe.Sizeof(_a) and INTERFACE.size - or at least for unsafe.Sizeof() to consistently
return the same result for package-level variables declared prior to its invocation.

@gopherbot
Copy link
Contributor Author

Comment 3 by eleanor@games-with-brains.com:

I should add that if I add an init() function and assign _b and _i in that then the
problem goes away, but this doesn't explain why in my code it is only the interface{}
type which behaves this way.
In the code where I observed this I'm also calculating size and value for all the
primitive types and for unsafe.Pointer as package-level operations and they're all
coming up with the right answer.

@adg
Copy link
Contributor

adg commented Mar 21, 2011

Comment 4:

Here's a stripped-down example:
package main
import "unsafe"
var i interface{} = 0
var s int = unsafe.Sizeof(i)
var t int
func init() {
        t = unsafe.Sizeof(i)
}
func main() {
        u := unsafe.Sizeof(i)
        println("global var", s)
        println("init", t)
        println("main", u)
}
Output:
global var -1000000000
init 16
main 16

Owner changed to @rsc.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented May 10, 2011

Comment 5:

This issue was closed by revision 3f335f8.

Status changed to Fixed.

@gopherbot
Copy link
Contributor Author

Comment 6 by eleanor@games-with-brains.com:

Hurrah!

@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc removed their assignment Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants