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

encoding/gob: cannot decode into top-level interface type #2367

Closed
rogpeppe opened this issue Oct 14, 2011 · 8 comments
Closed

encoding/gob: cannot decode into top-level interface type #2367

rogpeppe opened this issue Oct 14, 2011 · 8 comments
Milestone

Comments

@rogpeppe
Copy link
Contributor

This program fails because it cannot decode a (correctly registered) type into a
*interface{}. I can't see anything in the documentation that prohibits this, though I
think it's a reasonable use-case even it does.

output of program:
fail: gob: wrong type received for local value *interface { }: Foo = struct { }

06199863489f+ tip

package main
import (
    "os"
    "fmt"
    "gob"
    "io"
)

type Foo struct {
}

func main() {
    gob.Register(Foo{})
    r, w := io.Pipe()
    go func() {
        e := gob.NewEncoder(w)
        e.Encode(Foo{})
        w.Close()
    }()
    d := gob.NewDecoder(r)
    for {
        var v interface{}
        if err := d.Decode(&v); err != nil {
            fmt.Printf("fail: %v\n", err)
            os.Exit(1)
        }
        fmt.Printf("got %v of type %T\n", v, v)
    }
}
@rsc
Copy link
Contributor

rsc commented Oct 14, 2011

Comment 1:

Owner changed to @robpike.

Status changed to Accepted.

@gopherbot
Copy link

Comment 2 by robpike:

In gob streams, values to be encoded as interfaces must be sent as interfaces. In this
case, a struct is being sent and an interface is requested for the decode. This program
is therefore incorrect and in general cannot easily be made to work since the sender has
not explained the required interface specification in the stream.
Open to suggestions:
1) document this property better
2) provide better error message (although all the information is in the existing
message, it could always be clearer)
3) possibly make it work in cases where it can, specifically an empty interface
receiver. I do not favor this.

@rogpeppe
Copy link
Contributor Author

Comment 3:

I think it would be worth making this work - it's the classic use case of a stream of
differently typed messages. Requiring a container type just to get around this
restriction seems a bit silly to me.
However, looking at the protocol I do see the problem.
Better documentation is probably the answer.

@rsc
Copy link
Contributor

rsc commented Oct 14, 2011

Comment 4:

This has come up a few times now.  I think the solution
is to make the error message extra clear.

@rsc
Copy link
Contributor

rsc commented Dec 9, 2011

Comment 5:

Labels changed: added priority-later.

@rsc
Copy link
Contributor

rsc commented Dec 12, 2011

Comment 6:

Labels changed: added priority-go1.

@robpike
Copy link
Contributor

robpike commented Dec 14, 2011

Comment 7:

This issue was closed by revision ba576b2.

Status changed to Fixed.

@robpike
Copy link
Contributor

robpike commented Feb 10, 2012

Comment 8:

Issue #2938 has been merged into this issue.

@mikioh mikioh changed the title gob: cannot decode into top-level interface type encoding/gob: cannot decode into top-level interface type Feb 26, 2015
@rsc rsc added this to the Go1 milestone Apr 10, 2015
@rsc rsc removed the priority-go1 label Apr 10, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc unassigned robpike 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