<p dir="auto">Hello there !</p>
<p dir="auto">On any golang version  (1.5 or 1.6 ).</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="# http://play.golang.org/p/71ZtR0mX9K
package main

import (
    &quot;encoding/json&quot;
    &quot;fmt&quot;
)

type FooBar struct {
    Foo int `json:&quot;Foo,omitempty&quot;`
    Bar int `json:&quot;Bar,omitempty&quot;`
}

var (
    foo1 = `{&quot;Foo&quot;: 1}`
    bar1 = `{&quot;Bar&quot;: 1}`
)

func main() {
    fb := FooBar{}

    json.Unmarshal([]byte(foo1), &amp;fb)
    fmt.Printf(&quot;%+v\n&quot;, fb)

    json.Unmarshal([]byte(bar1), &amp;fb)
    fmt.Printf(&quot;%+v\n&quot;, fb)
}"><pre class="notranslate"><code class="notranslate"># http://play.golang.org/p/71ZtR0mX9K
package main

import (
    "encoding/json"
    "fmt"
)

type FooBar struct {
    Foo int `json:"Foo,omitempty"`
    Bar int `json:"Bar,omitempty"`
}

var (
    foo1 = `{"Foo": 1}`
    bar1 = `{"Bar": 1}`
)

func main() {
    fb := FooBar{}

    json.Unmarshal([]byte(foo1), &amp;fb)
    fmt.Printf("%+v\n", fb)

    json.Unmarshal([]byte(bar1), &amp;fb)
    fmt.Printf("%+v\n", fb)
}
</code></pre></div>
<p dir="auto">outputs</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="{Foo:1 Bar:0}
{Foo:1 Bar:0}"><pre class="notranslate"><code class="notranslate">{Foo:1 Bar:0}
{Foo:1 Bar:0}
</code></pre></div>
<p dir="auto">I assume it's because as its not set it's considered empty and omitted.</p>
<p dir="auto">But this can provoque weird behaviours when you reuse structs twice or have an unmarshal loop that read a file. Or worse, when you rewrite a that file with a loop in a different format.</p>
<hr>
<p dir="auto">Possible solutions:</p>
<ul dir="auto">
<li>add a <code class="notranslate">reset()</code> builtin, the one that's called just after allocation ? How would that work with pointers ?</li>
<li>make the encoding pkgs reset unset fields in <em>Unmarshal</em> using reflection ?</li>
<li>just tell people to be careful</li>
</ul>
<p dir="auto">cheers !</p>
<pre class="notranslate">I have a program that listens on tcp port 8080, gets its *net.TCPListener's File()
*os.File, and passes that to a child process via exec.Command.ExtraFiles.  The idea is
for the child to then use that listener with net.FileListener.

As a test, I wanted to verify that the child would fail to re-listen on that port.

On Linux, as expected, the child gets an error trying to re-listen on port 8080.

On OS X, the listen succeeds (and lsof shows two entries with identical contents), but
the accept hangs forever on the second dup listener (which in itself isn't surprising). 
What's surprising is that the dup Listen even succeeded.

I'd like to know if OS X just sucks, or we have some portability problem here.

I can refine this to a test case, but filing this bug before I forget.</pre>