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 <tapi...@gmail.com> 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 then depends on trivial differences that may affect
>> CPU loads/stores, instruction ordering, register usage, etc isn't
>> surprising.
>>
>> //jb
>
>
>
> Just check the Go runtime code, the signature of the channel send function
> is
>
> func chansend(c *hchan, ep unsafe.Pointer, block bool, callerpc uintptr)
> bool {
>
> where ep is a pointer to the sent value.
> Apparently, if the sent value is expression of a pure pointer dereference,
> the pointer will be passed as the ep argument,
> For other cases, the sent expression will get evaluated firstly and store
> the result in a temp value, then pass the address of temp value as the ep
> argument.
>
I can't find strong evidences to prove this is a bug.
I just fell it is some counter-intuitive.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
