Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Volker Dobler]

On Tuesday, 27 February 2018 08:17:20 UTC+1, di...@veryhaha.com wrote:
>
> ok, this is really make gophers worry about whether or not the pointer 
> atomic functions should be used.
>

No, probably this is much less worrying as you think.
Take a look as the documentation of sync/atomic:
"These functions require great care to be used correctly.
Except for special, low-level applications, synchronization
is better done with channels or the facilities of the
sync package."
The package itself says "do not use me", so just don't.

If a sticker on something reads "Hot! Do not touch!" then
sensible people just don't touch. They do not worry whether
to touch or not; they are happily not-touching.

V.

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Jan Mercl]

On Tue, Feb 27, 2018 at 8:17 AM  wrote:

> ok, this is really make gophers worry about whether or not the pointer
atomic functions should be used.

What to worry about? Under the Go 1 compatibility promise, the sync/atomic
package is going nowhere, IIUC.

-- 

-j

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

On Monday, February 26, 2018 at 11:21:43 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Feb 26, 2018 at 7:20 PM,   
> wrote: 
> > 
> > On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Mon, Feb 26, 2018 at 9:42 AM,   wrote: 
> >> > 
> >> > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: 
> >> >> 
> >> >> On 26 Feb 2018, at 18:21, "di...@veryhaha.com"  
> >> >> wrote: 
> >> >> 
> >> >> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: 
> >> >>> 
> >> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: 
> >> >>> 
> >> >>> 
> >> >>> Will the "sync/atomic" package get broken? 
> >> >>> This atomic package imports unsafe. 
> >> >>> 
> >> >>> 
> >> >>> If changes to unsafe break sync/atomic it’s up to the Go team to 
> fix 
> >> >>> sync/atomic before releasing. Much like it’s up to other package 
> >> >>> authors to 
> >> >>> make sure their packages work when unsafe changes, if they depend 
> on 
> >> >>> package 
> >> >>> unsafe. You can depend on sync/atomic working. 
> >> >> 
> >> >> Show Quoted Content 
> >> >>> 
> >> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: 
> >> >>> 
> >> >>> 
> >> >>> Will the "sync/atomic" package get broken? 
> >> >>> This atomic package imports unsafe. 
> >> >>> 
> >> >>> 
> >> >>> If changes to unsafe break sync/atomic it’s up to the Go team to 
> fix 
> >> >>> sync/atomic before releasing. Much like it’s up to other package 
> >> >>> authors to 
> >> >>> make sure their packages work when unsafe changes, if they depend 
> on 
> >> >>> package 
> >> >>> unsafe. You can depend on sync/atomic working. 
> >> >>> 
> >> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: 
> >> >>> 
> >> >>> 
> >> >>> Will the "sync/atomic" package get broken? 
> >> >>> This atomic package imports unsafe. 
> >> >>> 
> >> >>> 
> >> >>> If changes to unsafe break sync/atomic it’s up to the Go team to 
> fix 
> >> >>> sync/atomic before releasing. Much like it’s up to other package 
> >> >>> authors to 
> >> >>> make sure their packages work when unsafe changes, if they depend 
> on 
> >> >>> package 
> >> >>> unsafe. You can depend on sync/atomic working. 
> >> >> 
> >> >> 
> >> >> I mean whether or not the prototypes of the pointer functions in the 
> >> >> atomic packages will change? 
> >> >> 
> >> >> 
> >> >> I think it's a safe bet that unsafe.Pointer will continue to exist. 
> >> >> 
> >> >> //jb 
> >> > 
> >> > 
> >> > But even if it exits, those pointer atomic functions will still 
> become 
> >> > unusable if the unsafe mechanism is not supported any more. 
> >> 
> >> The Go 1 compatibility guarantee, applied to the sync/atomic package, 
> >> ensures that the type unsafe.Pointer will continue to exist for the 
> >> duration of Go 1. 
> >> 
> >> However, the precise details of how unsafe.Pointer may be used are 
> >> permitted to change.  And, in fact, they have changed in the past: 
> >> older versions of Go permitted uses of unsafe.Pointer that current 
> >> versions of Go do not permit. 
> > 
> > 
> > ok, I see. 
> > 
> > My current understanding is, 
> > to use the atomic pointer functions, the unsafe package must be 
> imported, 
> > so the uses of the atomic pointer functions may become invalid tomorrow. 
>
> I suppose that is one way of looking at it.  I would look at it the 
> other way around: as long as unsafe.Pointer is a meaningful type, the 
> sync/atomic unsafe.Pointer functions will work as expected.  If the 
> unsafe package ever changes such that it is invalid to use 
> unsafe.Pointer, then the sync/atomic unsafe.Pointer functions will 
> become useless because there is no way to get the values needed to 
> call them in a useful way. 
>

ok, this is really make gophers worry about whether or not the pointer 
atomic functions should be used.
 

>
> Ian 
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Ian Lance Taylor]

On Mon, Feb 26, 2018 at 7:20 PM,   wrote:
>
> On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor wrote:
>>
>> On Mon, Feb 26, 2018 at 9:42 AM,   wrote:
>> >
>> > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote:
>> >>
>> >> On 26 Feb 2018, at 18:21, "di...@veryhaha.com" 
>> >> wrote:
>> >>
>> >> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote:
>> >>>
>> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>> >>>
>> >>>
>> >>> Will the "sync/atomic" package get broken?
>> >>> This atomic package imports unsafe.
>> >>>
>> >>>
>> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix
>> >>> sync/atomic before releasing. Much like it’s up to other package
>> >>> authors to
>> >>> make sure their packages work when unsafe changes, if they depend on
>> >>> package
>> >>> unsafe. You can depend on sync/atomic working.
>> >>
>> >> Show Quoted Content
>> >>>
>> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>> >>>
>> >>>
>> >>> Will the "sync/atomic" package get broken?
>> >>> This atomic package imports unsafe.
>> >>>
>> >>>
>> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix
>> >>> sync/atomic before releasing. Much like it’s up to other package
>> >>> authors to
>> >>> make sure their packages work when unsafe changes, if they depend on
>> >>> package
>> >>> unsafe. You can depend on sync/atomic working.
>> >>>
>> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>> >>>
>> >>>
>> >>> Will the "sync/atomic" package get broken?
>> >>> This atomic package imports unsafe.
>> >>>
>> >>>
>> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix
>> >>> sync/atomic before releasing. Much like it’s up to other package
>> >>> authors to
>> >>> make sure their packages work when unsafe changes, if they depend on
>> >>> package
>> >>> unsafe. You can depend on sync/atomic working.
>> >>
>> >>
>> >> I mean whether or not the prototypes of the pointer functions in the
>> >> atomic packages will change?
>> >>
>> >>
>> >> I think it's a safe bet that unsafe.Pointer will continue to exist.
>> >>
>> >> //jb
>> >
>> >
>> > But even if it exits, those pointer atomic functions will still become
>> > unusable if the unsafe mechanism is not supported any more.
>>
>> The Go 1 compatibility guarantee, applied to the sync/atomic package,
>> ensures that the type unsafe.Pointer will continue to exist for the
>> duration of Go 1.
>>
>> However, the precise details of how unsafe.Pointer may be used are
>> permitted to change.  And, in fact, they have changed in the past:
>> older versions of Go permitted uses of unsafe.Pointer that current
>> versions of Go do not permit.
>
>
> ok, I see.
>
> My current understanding is,
> to use the atomic pointer functions, the unsafe package must be imported,
> so the uses of the atomic pointer functions may become invalid tomorrow.

I suppose that is one way of looking at it.  I would look at it the
other way around: as long as unsafe.Pointer is a meaningful type, the
sync/atomic unsafe.Pointer functions will work as expected.  If the
unsafe package ever changes such that it is invalid to use
unsafe.Pointer, then the sync/atomic unsafe.Pointer functions will
become useless because there is no way to get the values needed to
call them in a useful way.

Ian

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Feb 26, 2018 at 9:42 AM,   
> wrote: 
> > 
> > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: 
> >> 
> >> On 26 Feb 2018, at 18:21, "di...@veryhaha.com"  
> wrote: 
> >> 
> >> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: 
> >>> 
> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: 
> >>> 
> >>> 
> >>> Will the "sync/atomic" package get broken? 
> >>> This atomic package imports unsafe. 
> >>> 
> >>> 
> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix 
> >>> sync/atomic before releasing. Much like it’s up to other package 
> authors to 
> >>> make sure their packages work when unsafe changes, if they depend on 
> package 
> >>> unsafe. You can depend on sync/atomic working. 
> >> 
> >> Show Quoted Content 
> >>> 
> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: 
> >>> 
> >>> 
> >>> Will the "sync/atomic" package get broken? 
> >>> This atomic package imports unsafe. 
> >>> 
> >>> 
> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix 
> >>> sync/atomic before releasing. Much like it’s up to other package 
> authors to 
> >>> make sure their packages work when unsafe changes, if they depend on 
> package 
> >>> unsafe. You can depend on sync/atomic working. 
> >>> 
> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: 
> >>> 
> >>> 
> >>> Will the "sync/atomic" package get broken? 
> >>> This atomic package imports unsafe. 
> >>> 
> >>> 
> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix 
> >>> sync/atomic before releasing. Much like it’s up to other package 
> authors to 
> >>> make sure their packages work when unsafe changes, if they depend on 
> package 
> >>> unsafe. You can depend on sync/atomic working. 
> >> 
> >> 
> >> I mean whether or not the prototypes of the pointer functions in the 
> >> atomic packages will change? 
> >> 
> >> 
> >> I think it's a safe bet that unsafe.Pointer will continue to exist. 
> >> 
> >> //jb 
> > 
> > 
> > But even if it exits, those pointer atomic functions will still become 
> > unusable if the unsafe mechanism is not supported any more. 
>
> The Go 1 compatibility guarantee, applied to the sync/atomic package, 
> ensures that the type unsafe.Pointer will continue to exist for the 
> duration of Go 1. 
>
> However, the precise details of how unsafe.Pointer may be used are 
> permitted to change.  And, in fact, they have changed in the past: 
> older versions of Go permitted uses of unsafe.Pointer that current 
> versions of Go do not permit. 
>

ok, I see.

My current understanding is,
to use the atomic pointer functions, the unsafe package must be imported,
so the uses of the atomic pointer functions may become invalid tomorrow.
 

>
> Ian 
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Ian Lance Taylor]

On Mon, Feb 26, 2018 at 9:42 AM,   wrote:
>
> On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote:
>>
>> On 26 Feb 2018, at 18:21, "di...@veryhaha.com"  wrote:
>>
>> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote:
>>>
>>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>>>
>>>
>>> Will the "sync/atomic" package get broken?
>>> This atomic package imports unsafe.
>>>
>>>
>>> If changes to unsafe break sync/atomic it’s up to the Go team to fix
>>> sync/atomic before releasing. Much like it’s up to other package authors to
>>> make sure their packages work when unsafe changes, if they depend on package
>>> unsafe. You can depend on sync/atomic working.
>>
>> Show Quoted Content
>>>
>>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>>>
>>>
>>> Will the "sync/atomic" package get broken?
>>> This atomic package imports unsafe.
>>>
>>>
>>> If changes to unsafe break sync/atomic it’s up to the Go team to fix
>>> sync/atomic before releasing. Much like it’s up to other package authors to
>>> make sure their packages work when unsafe changes, if they depend on package
>>> unsafe. You can depend on sync/atomic working.
>>>
>>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>>>
>>>
>>> Will the "sync/atomic" package get broken?
>>> This atomic package imports unsafe.
>>>
>>>
>>> If changes to unsafe break sync/atomic it’s up to the Go team to fix
>>> sync/atomic before releasing. Much like it’s up to other package authors to
>>> make sure their packages work when unsafe changes, if they depend on package
>>> unsafe. You can depend on sync/atomic working.
>>
>>
>> I mean whether or not the prototypes of the pointer functions in the
>> atomic packages will change?
>>
>>
>> I think it's a safe bet that unsafe.Pointer will continue to exist.
>>
>> //jb
>
>
> But even if it exits, those pointer atomic functions will still become
> unusable if the unsafe mechanism is not supported any more.

The Go 1 compatibility guarantee, applied to the sync/atomic package,
ensures that the type unsafe.Pointer will continue to exist for the
duration of Go 1.

However, the precise details of how unsafe.Pointer may be used are
permitted to change.  And, in fact, they have changed in the past:
older versions of Go permitted uses of unsafe.Pointer that current
versions of Go do not permit.

Ian

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote:
>
> On 26 Feb 2018, at 18:21, "di...@veryhaha.com " <
> di...@veryhaha.com > wrote:
>
> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: 
> <#34A5B26F-AB6C-4559-A17D-D8137AC52784@kastelo.net_> 
> <#34A5B26F-AB6C-4559-A17D-D8137AC52784@kastelo.net_> 
>>
>> <#34A5B26F-AB6C-4559-A17D-D8137AC52784@kastelo.net_> 
>> On 26 Feb 2018, at 16:38, 
>> <#34A5B26F-AB6C-4559-A17D-D8137AC52784@kastelo.net_>di...@veryhaha.com 
>> wrote:
>>
>>
>> Will the "sync/atomic" package get broken?
>> This atomic package imports unsafe.
>>
>>
>> If changes to unsafe break sync/atomic it’s up to the Go team to fix 
>> sync/atomic before releasing. Much like it’s up to other package authors to 
>> make sure their packages work when unsafe changes, if they depend on 
>> package unsafe. You can depend on sync/atomic working.
>>
> Show Quoted Content
>
>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>>
>>
>> Will the "sync/atomic" package get broken?
>> This atomic package imports unsafe.
>>
>>
>> If changes to unsafe break sync/atomic it’s up to the Go team to fix 
>> sync/atomic before releasing. Much like it’s up to other package authors to 
>> make sure their packages work when unsafe changes, if they depend on 
>> package unsafe. You can depend on sync/atomic working.
>>
> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:
>>
>>
>> Will the "sync/atomic" package get broken?
>> This atomic package imports unsafe.
>>
>>
>> If changes to unsafe break sync/atomic it’s up to the Go team to fix 
>> sync/atomic before releasing. Much like it’s up to other package authors to 
>> make sure their packages work when unsafe changes, if they depend on 
>> package unsafe. You can depend on sync/atomic working.
>>
>
> I mean whether or not the prototypes of the pointer functions in the 
> atomic packages will change?
>
>
> I think it's a safe bet that unsafe.Pointer will continue to exist. 
>
> //jb
>

But even if it exits, those pointer atomic functions will still become 
unusable if the unsafe mechanism is not supported any more.
 

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Jakob Borg]

On 26 Feb 2018, at 18:21, "d...@veryhaha.com" 
> wrote:

On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote:
On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:

Will the "sync/atomic" package get broken?
This atomic package imports unsafe.

If changes to unsafe break sync/atomic it’s up to the Go team to fix 
sync/atomic before releasing. Much like it’s up to other package authors to 
make sure their packages work when unsafe changes, if they depend on package 
unsafe. You can depend on sync/atomic working.
Show Quoted Content
On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:

Will the "sync/atomic" package get broken?
This atomic package imports unsafe.

If changes to unsafe break sync/atomic it’s up to the Go team to fix 
sync/atomic before releasing. Much like it’s up to other package authors to 
make sure their packages work when unsafe changes, if they depend on package 
unsafe. You can depend on sync/atomic working.
On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote:

Will the "sync/atomic" package get broken?
This atomic package imports unsafe.

If changes to unsafe break sync/atomic it’s up to the Go team to fix 
sync/atomic before releasing. Much like it’s up to other package authors to 
make sure their packages work when unsafe changes, if they depend on package 
unsafe. You can depend on sync/atomic working.

I mean whether or not the prototypes of the pointer functions in the atomic 
packages will change?

I think it's a safe bet that unsafe.Pointer will continue to exist.

//jb

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

So, the sync/atomic package is possible to break tomorrow?

On Monday, February 26, 2018 at 12:24:35 PM UTC-5, Andy Balholm wrote:
>
> Oops. I left out a couple words. I meant “does not keep”. 
>
> Andy 
>
> > On Feb 26, 2018, at 9:23 AM, Andy Balholm  > wrote: 
> > 
> > There is no guarantee that the unsafe package even exists in every 
> implementation of Go. For example, I really doubt that GopherJS has it. But 
> that keep GopherJS from being compliant with the Go spec and the Go 1 
> compatibility guarantee. (I’m not sure whether GopherJS is to the point of 
> full compliance yet, but my point here is that it doesn’t need “unsafe” in 
> order to reach that point.) 
> > 
> > Andy 
> > 
> >> On Feb 26, 2018, at 7:38 AM, di...@veryhaha.com  wrote: 
> >> 
> >> Will the 3 APIs and the unsafe.Pointer be always there? 
> >> Will the "sync/atomic" package get broken? 
> >> This atomic package imports unsafe. 
> > 
>
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Andy Balholm]

Oops. I left out a couple words. I meant “does not keep”.

Andy

> On Feb 26, 2018, at 9:23 AM, Andy Balholm  wrote:
> 
> There is no guarantee that the unsafe package even exists in every 
> implementation of Go. For example, I really doubt that GopherJS has it. But 
> that keep GopherJS from being compliant with the Go spec and the Go 1 
> compatibility guarantee. (I’m not sure whether GopherJS is to the point of 
> full compliance yet, but my point here is that it doesn’t need “unsafe” in 
> order to reach that point.)
> 
> Andy
> 
>> On Feb 26, 2018, at 7:38 AM, d...@veryhaha.com wrote:
>> 
>> Will the 3 APIs and the unsafe.Pointer be always there?
>> Will the "sync/atomic" package get broken?
>> This atomic package imports unsafe.
> 

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Andy Balholm]

There is no guarantee that the unsafe package even exists in every 
implementation of Go. For example, I really doubt that GopherJS has it. But 
that keep GopherJS from being compliant with the Go spec and the Go 1 
compatibility guarantee. (I’m not sure whether GopherJS is to the point of full 
compliance yet, but my point here is that it doesn’t need “unsafe” in order to 
reach that point.)

Andy

> On Feb 26, 2018, at 7:38 AM, d...@veryhaha.com wrote:
> 
> Will the 3 APIs and the unsafe.Pointer be always there?
> Will the "sync/atomic" package get broken?
> This atomic package imports unsafe.

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote:
>
> On 26 Feb 2018, at 16:38, di...@veryhaha.com  wrote:
>
>
> Will the "sync/atomic" package get broken?
> This atomic package imports unsafe.
>
>
> If changes to unsafe break sync/atomic it’s up to the Go team to fix 
> sync/atomic before releasing. Much like it’s up to other package authors to 
> make sure their packages work when unsafe changes, if they depend on 
> package unsafe. You can depend on sync/atomic working.
>

I mean whether or not the prototypes of the pointer functions in the atomic 
packages will change?
 

>
> //jb
>
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Jakob Borg]

On 26 Feb 2018, at 16:38, d...@veryhaha.com wrote:

Will the "sync/atomic" package get broken?
This atomic package imports unsafe.

If changes to unsafe break sync/atomic it’s up to the Go team to fix 
sync/atomic before releasing. Much like it’s up to other package authors to 
make sure their packages work when unsafe changes, if they depend on package 
unsafe. You can depend on sync/atomic working.

//jb

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Michael Jones]

Digg:

If (thought experiment) Go had "const" for variables meaning "you can only
set this once"...

var x const int = 32

...and you tried to use unsafe to get the address of x and remove its
const-ness and then assign through it the value  to x, what do you
think would and should happen?

a. x=, which seems what you expected
b. x=32, a silent failure (frightening to debug!)
c. panic, the observed behavior

Even though this is just a thought experiment, it is VERY CLOSE to the true
situation for Go's immutable strings.
https://golang.org/ref/spec#String_types

"Strings are immutable: once created, it is impossible to change the
contents of a string."


What you are trying to do is to make this impossible change. Don't do that.
The result, even if you could do it, would not be Go.


On Mon, Feb 26, 2018 at 5:44 AM, Rob Pike  wrote:

> No. As I said, there are no guarantees. As it says in
> https://golang.org/doc/go1compat:
>
>
>- Use of package unsafe. Packages that import unsafe
> may depend on internal properties of
>the Go implementation. We reserve the right to make changes to the
>implementation that may break such programs.
>
>
>
>
> On Mon, Feb 26, 2018 at 1:15 PM,  wrote:
>
>>
>>
>> On Sunday, February 25, 2018 at 7:38:22 PM UTC-5, Rob 'Commander' Pike
>> wrote:
>>>
>>> The main rule about unsafe is that your program might work or might not.
>>> There are no guarantees either way. That's why it's called 'unsafe' and why
>>> you shouldn't use it. Your program that 'works' today could break tomorrow.
>>>
>>
>> ok, but, is there always an unsafe alternative/variant existing later?
>>
>>
>>>
>>> -rob
>>>
>>>
>>> On Mon, Feb 26, 2018 at 4:43 AM, Marvin Renich  wrote:
>>>
 * di...@veryhaha.com  [180225 11:37]:
 > I think I get it.
 > Because the above program tries to modify the constant (or program)
 zone,
 > which is not allowed.
 > The following program works:

 But, note that the language spec does not guarantee it to work.  The
 compiler is free to recognize what that first line is doing and optimize
 the assignment into a string in a R/O memory segment.  The optimization
 is legal because the compiler does not have to recognize the use of
 unsafe to determine the programmer's intent to subvert the type system.

 > package main
 >
 > import "fmt"
 > import "unsafe"
 > import "reflect"
 >
 > func main() {
 > s := string([]byte{'k', 'e', 'e', 'p'})
 > hdr := (*reflect.StringHeader)(unsafe.Pointer())
 > byteSequence := (*byte)(unsafe.Pointer(hdr.Data))
 > fmt.Println(string(*byteSequence)) // k
 > *byteSequence = 'j' // crash here
 > fmt.Println(s) // expect: jeep
 > }

 ...Marvin

 --
 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>> 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.
>>
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Rob Pike]

No. As I said, there are no guarantees. As it says in
https://golang.org/doc/go1compat:


   - Use of package unsafe. Packages that import unsafe
    may depend on internal properties of
   the Go implementation. We reserve the right to make changes to the
   implementation that may break such programs.




On Mon, Feb 26, 2018 at 1:15 PM,  wrote:

>
>
> On Sunday, February 25, 2018 at 7:38:22 PM UTC-5, Rob 'Commander' Pike
> wrote:
>>
>> The main rule about unsafe is that your program might work or might not.
>> There are no guarantees either way. That's why it's called 'unsafe' and why
>> you shouldn't use it. Your program that 'works' today could break tomorrow.
>>
>
> ok, but, is there always an unsafe alternative/variant existing later?
>
>
>>
>> -rob
>>
>>
>> On Mon, Feb 26, 2018 at 4:43 AM, Marvin Renich  wrote:
>>
>>> * di...@veryhaha.com  [180225 11:37]:
>>> > I think I get it.
>>> > Because the above program tries to modify the constant (or program)
>>> zone,
>>> > which is not allowed.
>>> > The following program works:
>>>
>>> But, note that the language spec does not guarantee it to work.  The
>>> compiler is free to recognize what that first line is doing and optimize
>>> the assignment into a string in a R/O memory segment.  The optimization
>>> is legal because the compiler does not have to recognize the use of
>>> unsafe to determine the programmer's intent to subvert the type system.
>>>
>>> > package main
>>> >
>>> > import "fmt"
>>> > import "unsafe"
>>> > import "reflect"
>>> >
>>> > func main() {
>>> > s := string([]byte{'k', 'e', 'e', 'p'})
>>> > hdr := (*reflect.StringHeader)(unsafe.Pointer())
>>> > byteSequence := (*byte)(unsafe.Pointer(hdr.Data))
>>> > fmt.Println(string(*byteSequence)) // k
>>> > *byteSequence = 'j' // crash here
>>> > fmt.Println(s) // expect: jeep
>>> > }
>>>
>>> ...Marvin
>>>
>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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.
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

On Sunday, February 25, 2018 at 7:38:22 PM UTC-5, Rob 'Commander' Pike 
wrote:
>
> The main rule about unsafe is that your program might work or might not. 
> There are no guarantees either way. That's why it's called 'unsafe' and why 
> you shouldn't use it. Your program that 'works' today could break tomorrow.
>

ok, but, is there always an unsafe alternative/variant existing later?
 

>
> -rob
>
>
> On Mon, Feb 26, 2018 at 4:43 AM, Marvin Renich  > wrote:
>
>> * di...@veryhaha.com   
>> [180225 11:37]:
>> > I think I get it.
>> > Because the above program tries to modify the constant (or program) 
>> zone,
>> > which is not allowed.
>> > The following program works:
>>
>> But, note that the language spec does not guarantee it to work.  The
>> compiler is free to recognize what that first line is doing and optimize
>> the assignment into a string in a R/O memory segment.  The optimization
>> is legal because the compiler does not have to recognize the use of
>> unsafe to determine the programmer's intent to subvert the type system.
>>
>> > package main
>> >
>> > import "fmt"
>> > import "unsafe"
>> > import "reflect"
>> >
>> > func main() {
>> > s := string([]byte{'k', 'e', 'e', 'p'})
>> > hdr := (*reflect.StringHeader)(unsafe.Pointer())
>> > byteSequence := (*byte)(unsafe.Pointer(hdr.Data))
>> > fmt.Println(string(*byteSequence)) // k
>> > *byteSequence = 'j' // crash here
>> > fmt.Println(s) // expect: jeep
>> > }
>>
>> ...Marvin
>>
>> --
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Rob Pike]

The main rule about unsafe is that your program might work or might not.
There are no guarantees either way. That's why it's called 'unsafe' and why
you shouldn't use it. Your program that 'works' today could break tomorrow.

-rob


On Mon, Feb 26, 2018 at 4:43 AM, Marvin Renich  wrote:

> * d...@veryhaha.com  [180225 11:37]:
> > I think I get it.
> > Because the above program tries to modify the constant (or program) zone,
> > which is not allowed.
> > The following program works:
>
> But, note that the language spec does not guarantee it to work.  The
> compiler is free to recognize what that first line is doing and optimize
> the assignment into a string in a R/O memory segment.  The optimization
> is legal because the compiler does not have to recognize the use of
> unsafe to determine the programmer's intent to subvert the type system.
>
> > package main
> >
> > import "fmt"
> > import "unsafe"
> > import "reflect"
> >
> > func main() {
> > s := string([]byte{'k', 'e', 'e', 'p'})
> > hdr := (*reflect.StringHeader)(unsafe.Pointer())
> > byteSequence := (*byte)(unsafe.Pointer(hdr.Data))
> > fmt.Println(string(*byteSequence)) // k
> > *byteSequence = 'j' // crash here
> > fmt.Println(s) // expect: jeep
> > }
>
> ...Marvin
>
> --
> 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.
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Marvin Renich]

* d...@veryhaha.com  [180225 11:37]:
> I think I get it.
> Because the above program tries to modify the constant (or program) zone, 
> which is not allowed.
> The following program works:

But, note that the language spec does not guarantee it to work.  The
compiler is free to recognize what that first line is doing and optimize
the assignment into a string in a R/O memory segment.  The optimization
is legal because the compiler does not have to recognize the use of
unsafe to determine the programmer's intent to subvert the type system.

> package main
> 
> import "fmt"
> import "unsafe"
> import "reflect"
> 
> func main() {
> s := string([]byte{'k', 'e', 'e', 'p'})
> hdr := (*reflect.StringHeader)(unsafe.Pointer())
> byteSequence := (*byte)(unsafe.Pointer(hdr.Data))
> fmt.Println(string(*byteSequence)) // k
> *byteSequence = 'j' // crash here
> fmt.Println(s) // expect: jeep
> }

...Marvin

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

On Sunday, February 25, 2018 at 10:01:44 AM UTC-5, Jan Mercl wrote:
>
>
> On Sun, Feb 25, 2018 at 3:20 PM  wrote:
>
> > I think the unsafe rules allow this.
>
> Yes, but using unsafe provides no guarantees about writable memory.
>
> > I never expect it will crash, for I can't get any information about the 
> write protection mechanism.
>
> That's not part of the memory model and most probably never will. Layout 
> and/or protection of the sections is the design choice of the compiler 
> writer. But text constants are put in a R/O segment by many, if not most 
> AOT compilers.
>
>
I think I get it.
Because the above program tries to modify the constant (or program) zone, 
which is not allowed.
The following program works:

package main

import "fmt"
import "unsafe"
import "reflect"

func main() {
s := string([]byte{'k', 'e', 'e', 'p'})
hdr := (*reflect.StringHeader)(unsafe.Pointer())
byteSequence := (*byte)(unsafe.Pointer(hdr.Data))
fmt.Println(string(*byteSequence)) // k
*byteSequence = 'j' // crash here
fmt.Println(s) // expect: jeep
}
 

>
> -- 
>
> -j
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Jan Mercl]

On Sun, Feb 25, 2018 at 3:20 PM  wrote:

> I think the unsafe rules allow this.

Yes, but using unsafe provides no guarantees about writable memory.

> I never expect it will crash, for I can't get any information about the
write protection mechanism.

That's not part of the memory model and most probably never will. Layout
and/or protection of the sections is the design choice of the compiler
writer. But text constants are put in a R/O segment by many, if not most
AOT compilers.


-- 

-j

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[digg]

On Sunday, February 25, 2018 at 8:57:53 AM UTC-5, Jan Mercl wrote:
>
> On Sun, Feb 25, 2018 at 2:29 PM  wrote:
>
> > Why does the following program crash?
>
> Because the program attempts to write to the R/O text segment. Why is it 
> doing that?
>

Yes. I will not do this in formal code.
This is just to learn how to use unsafe mechanism.
I think the unsafe rules allow this.
I never expect it will crash, for I can't get any information about the 
write protection mechanism.
 

>
> -- 
>
> -j
>

-- 
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.

Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Jan Mercl]

On Sun, Feb 25, 2018 at 2:29 PM  wrote:

> Why does the following program crash?

Because the program attempts to write to the R/O text segment. Why is it
doing that?

-- 

-j

-- 
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.