On Wed, Sep 06, 2017 at 04:26:09AM -0700, T L wrote:
> > > It is just weird that the evaluation timing of *p is different to other
> > expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
> >
> > The value depends on a data race so it's entirely undefined in all cases.
> > That the
On Wednesday, September 6, 2017 at 7:38:04 AM UTC-4, T L wrote:
>
>
>
> On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote:
>>
>> On 6 Sep 2017, at 10:28, T L wrote:
>> > It is just weird that the evaluation timing of *p is different to other
>>
On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote:
>
> On 6 Sep 2017, at 10:28, T L wrote:
> > It is just weird that the evaluation timing of *p is different to other
> expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
>
> The value depends
On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote:
>
> On 6 Sep 2017, at 10:28, T L wrote:
> > It is just weird that the evaluation timing of *p is different to other
> expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
>
> The value depends
On 6 Sep 2017, at 10:28, T L wrote:
> It is just weird that the evaluation timing of *p is different to other
> expressions, such as, *p+0, *p*1, func()int{return *p}m etc.
The value depends on a data race so it's entirely undefined in all cases. That
the actual outcome
On Tuesday, September 5, 2017 at 11:04:52 PM UTC-4, Jesse McNelis wrote:
>
> On Wed, Sep 6, 2017 at 2:26 AM, T L
> wrote:
> >
> > I mean it can be viewed as a bug for inconsistency.
> > But from the memory model view, it can also not be viewed as a bug.
> >
>
> It's
On Wed, Sep 6, 2017 at 2:26 AM, T L wrote:
>
> I mean it can be viewed as a bug for inconsistency.
> But from the memory model view, it can also not be viewed as a bug.
>
It's not a bug. The code is clearly expecting some ordering between
internal operations within two
On Tuesday, September 5, 2017 at 12:20:02 PM UTC-4, T L wrote:
>
> IMO, I think this is a bug.
>
I mean it can be viewed as a bug for inconsistency.
But from the memory model view, it can also not be viewed as a bug.
>
> On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote:
>>
>>
IMO, I think this is a bug.
On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote:
>
> BTW, the following one also prints 10.
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> var num = 10
> var p =
>
> c := make(chan int)
>
> go func() {
>
BTW, the following one also prints 10.
package main
import (
"fmt"
"time"
)
func main() {
var num = 10
var p =
c := make(chan int)
go func() {
c <- *p * 1 // with this line we will get 11 from channel c
//c <- num // with this line we will get 10 from
The program is really racy, but the result is also really some
counter-intuitive.
The following program also print 10, which means evaluation of pointer
dereference
is some different to evaluation of other expressions in flow.
package main
import (
"fmt"
"time"
)
func main() {
var
On Tue, Sep 5, 2017 at 10:34 AM, Marlon Che wrote:
> Hi everyone!
> Please help me figure out the two different results of following code:
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> var num = 10
> var p =
>
> c := make(chan
12 matches
Mail list logo