On Sat, Jan 26, 2019 at 7:56 AM Marvin Renich wrote:
>
> * Ian Lance Taylor [190125 18:11]:
> > On Fri, Jan 25, 2019 at 2:59 PM wrote:
> > > I still can't find anything "authoritative and unambiguous" on this.
> > > Therefore apps are going to be released with bugs in them. Can
> > > someone
* Ian Lance Taylor [190125 18:11]:
> On Fri, Jan 25, 2019 at 2:59 PM wrote:
> > I still can't find anything "authoritative and unambiguous" on this.
> > Therefore apps are going to be released with bugs in them. Can
> > someone please say specifically when it is _not_ safe to use 64-bit
> >
On Fri, Jan 25, 2019 at 2:59 PM wrote:
>
> I still can't find anything "authoritative and unambiguous" on this.
> Therefore apps are going to be released with bugs in them. Can someone
> please say specifically when it is _not_ safe to use 64-bit atomic operations?
>
> When it is unsafe on a
I still can't find anything "authoritative and unambiguous" on this.
Therefore apps are going to be released with bugs in them. Can someone
please say specifically when it is _not_ safe to use 64-bit atomic
operations?
When it is unsafe on a 64-bit OS?
When it is unsafe on a 32-bit OS?
John
On Thursday, March 15, 2018 at 12:54:22 PM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Mar 15, 2018 at 8:11 AM, T L
> wrote:
> >
> > On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote:
> >>
> >>
> >> On Thu, Mar 15, 2018 at 3:29 PM T L
On Thu, Mar 15, 2018 at 8:11 AM, T L wrote:
>
> On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote:
>>
>>
>> On Thu, Mar 15, 2018 at 3:29 PM T L wrote:
>>
>> > I mean "always makes 64-bit words 64-bit aligned on i386 OSes."
>>
>> AFAIK,
On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote:
>
>
> On Thu, Mar 15, 2018 at 3:29 PM T L
> wrote:
>
> > I mean "always makes 64-bit words 64-bit aligned on i386 OSes."
>
> AFAIK, that's not the case, ie. not always.
>
> --
>
> -j
>
But it looks the
On Thu, Mar 15, 2018 at 3:29 PM T L wrote:
> I mean "always makes 64-bit words 64-bit aligned on i386 OSes."
AFAIK, that's not the case, ie. not always.
--
-j
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
On Thursday, March 15, 2018 at 10:09:36 AM UTC-4, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 7:43:33 AM UTC-5, T L wrote:
>>
>>
>>
>> On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote:
>>>
>>>
>>>
>>> On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote:
On Monday, February 6, 2017 at 7:43:33 AM UTC-5, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote:
>>
>>
>>
>> On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote:
>>>
>>>
>>>
>>> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
On Monday, February 6, 2017 at 11:16:22 AM UTC, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote:
>>
>>
>>
>> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
>>>
>>> On Sun, Feb 5, 2017 at 10:52 AM, T L wrote:
>>> > Ian,
On Monday, February 6, 2017 at 6:43:04 PM UTC+8, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Sun, Feb 5, 2017 at 10:52 AM, T L wrote:
>> > Ian, thanks for the answers.
>> >
>> > But I still not very confirm on many
On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
>
> On Sun, Feb 5, 2017 at 10:52 AM, T L
> wrote:
> > Ian, thanks for the answers.
> >
> > But I still not very confirm on many points.
> >
> > Up to now, there are two places mention the
On Monday, February 6, 2017 at 12:44:38 PM UTC+8, Ian Lance Taylor wrote:
>
> On Sun, Feb 5, 2017 at 8:15 PM, T L
> wrote:
> >
> > In fact, I still have another question needs to be clarify: what does
> the
> > "word" in "The first word in a global variable or in an
On Sun, Feb 5, 2017 at 8:15 PM, T L wrote:
>
> In fact, I still have another question needs to be clarify: what does the
> "word" in "The first word in a global variable or in an allocated struct or
> slice" mean?
> A field with the same length with int values?
In this case
On Sun, Feb 5, 2017 at 11:55 AM, T L wrote:
>
> In short, when structs and slices are used as the non-first fields of other
> structs,
> then the struct and slice fields may be not 64bit aligned on 32bit OSes.
>
> But what about arrays? Can the first word in an allocated
On Monday, February 6, 2017 at 3:55:35 AM UTC+8, T L wrote:
>
>
>
> On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Sun, Feb 5, 2017 at 10:52 AM, T L wrote:
>> > Ian, thanks for the answers.
>> >
>> > But I still not very confirm on many
On Monday, February 6, 2017 at 3:14:22 AM UTC+8, Ian Lance Taylor wrote:
>
> On Sun, Feb 5, 2017 at 10:52 AM, T L
> wrote:
> > Ian, thanks for the answers.
> >
> > But I still not very confirm on many points.
> >
> > Up to now, there are two places mention the
On Sun, Feb 5, 2017 at 10:52 AM, T L wrote:
> Ian, thanks for the answers.
>
> But I still not very confirm on many points.
>
> Up to now, there are two places mention the alignments in Go.
>
> The first is in the end of Go spec:
>
>
> Size and alignment guarantees
>
> For
On Sat, Feb 4, 2017 at 2:38 PM, Axel Wagner
wrote:
> On Sat, Feb 4, 2017 at 11:13 PM, Ian Lance Taylor wrote:
>>
>> The spec does not say that unsafe.Alignof(s.B) will return 8. In
>> fact, on 32-bit targets, with the gc toolchain, it will return
On Sat, Feb 4, 2017 at 11:13 PM, Ian Lance Taylor wrote:
> On Sat, Feb 4, 2017 at 7:33 AM, Axel Wagner
> wrote:
> >
> > I believe, that fields do not necessarily need to be properly aligned
> > (explaining 599). However, *structs* have a necessary
Basically, to most of your disagreements: I'm wildly guessing, trying to
make sense of the information I do have :) Just one specific answer:
On Sat, Feb 4, 2017 at 11:05 PM, Matt Harden wrote:
>
> Wait, I don't think you've explained why expvar.Float would be aligned
>
On Sat, Feb 4, 2017 at 7:33 AM, Axel Wagner
wrote:
>
> I believe, that fields do not necessarily need to be properly aligned
> (explaining 599). However, *structs* have a necessary alignment, as required
> by their fields. So, if you do
> type S struct {
> A
On Sat, Feb 4, 2017 at 7:34 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I find this an inappropriate answer. Yes, they need care, but it should at
> least be possible to figure out how to use them from reading documentation
> (carefully). I tend to agree, that
I find this an inappropriate answer. Yes, they need care, but it should at
least be possible to figure out how to use them from reading documentation
(carefully). I tend to agree, that neither the spec nor the documentation
of the atomic package is particularly helpful about these questions; at
On Sat, Feb 04, 2017 at 01:30:49AM -0800, T L wrote:
> Get it. This is quite bug prone to write programs on 64bit OSes and the
> programs are expected to run on 32bit OSes too.
Well, there's a reason the sync/atomic package docs have this statement
right at the top:
> These functions require
On Saturday, February 4, 2017 at 6:32:52 PM UTC+8, Axel Wagner wrote:
>
> The spec says this:
> https://golang.org/ref/spec#Size_and_alignment_guarantees
> Now, I can't really read from this whether this applies to fields or not.
> If it does, it would seem to me, that, indeed, WaitGroup
The spec says this:
https://golang.org/ref/spec#Size_and_alignment_guarantees
Now, I can't really read from this whether this applies to fields or not.
If it does, it would seem to me, that, indeed, WaitGroup wouldn't need to
use the trick it does.
For the example you name: It isn't particularly
On Saturday, February 4, 2017 at 2:18:44 PM UTC+8, Matt Harden wrote:
>
> https://play.golang.org/p/VWysBwbPCu
>
> The above program prints 64-bit aligned addresses on the playground, but
> that's a 64 bit platform (with 32 bit pointers). On a 32 bit platform x.j
> is not guaranteed to be
On Saturday, February 4, 2017 at 5:56:30 PM UTC+8, T L wrote:
>
>
>
> On Saturday, February 4, 2017 at 5:40:25 PM UTC+8, T L wrote:
>>
>>
>>
>> On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote:
>>>
>>> On Fri, Feb 3, 2017 at 5:38 AM, T L wrote:
>>> >
On Saturday, February 4, 2017 at 5:40:25 PM UTC+8, T L wrote:
>
>
>
> On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 3, 2017 at 5:38 AM, T L wrote:
>> > Why does WaitGroup.state method check 64-bit alignment at run time?
>> > Why
On Friday, February 3, 2017 at 10:44:26 PM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Feb 3, 2017 at 5:38 AM, T L
> wrote:
> > Why does WaitGroup.state method check 64-bit alignment at run time?
> > Why not make the state field as the first word of WaitGroup struct?
> >
On Saturday, February 4, 2017 at 2:51:53 PM UTC+8, Axel Wagner wrote:
>
> On Sat, Feb 4, 2017 at 5:49 AM, T L
> wrote:
>
>> On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote:
>>>
>>> Never mind; I just realized that a WaitGroup is not necessarily at the
On Sat, Feb 4, 2017 at 5:49 AM, T L wrote:
> On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote:
>>
>> Never mind; I just realized that a WaitGroup is not necessarily at the
>> start of an allocation or global variable.
>>
>
> Not very get it.
> Do you
https://play.golang.org/p/VWysBwbPCu
The above program prints 64-bit aligned addresses on the playground, but
that's a 64 bit platform (with 32 bit pointers). On a 32 bit platform x.j
is not guaranteed to be 64-bit aligned. The same would be true if we
substituted a WaitGroup for int64 in that
On Saturday, February 4, 2017 at 11:03:11 AM UTC+8, Matt Harden wrote:
>
> Never mind; I just realized that a WaitGroup is not necessarily at the
> start of an allocation or global variable.
>
Not very get it.
Do you mean WaitGroup will be embedded in other types?
So we can't use the 64bit
Never mind; I just realized that a WaitGroup is not necessarily at the
start of an allocation or global variable.
On Fri, Feb 3, 2017 at 7:01 PM Matt Harden wrote:
> Doesn't the statement "32-bit compilers to not ensure [64 bit alignment at
> the start of an allocation]"
Doesn't the statement "32-bit compilers to not ensure [64 bit alignment at
the start of an allocation]" contradict the sync/atomic statement "The
first word in a global variable or in an allocated struct or slice can be
relied upon to be 64-bit aligned."?
On Fri, Feb 3, 2017 at 6:44 AM Ian Lance
On Fri, Feb 3, 2017 at 5:38 AM, T L wrote:
> Why does WaitGroup.state method check 64-bit alignment at run time?
> Why not make the state field as the first word of WaitGroup struct?
>
> // https://golang.org/src/sync/waitgroup.go?s=1857:1892#L20
>
> type WaitGroup struct {
>
Why does WaitGroup.state method check 64-bit alignment at run time?
Why not make the state field as the first word of WaitGroup struct?
// https://golang.org/src/sync/waitgroup.go?s=1857:1892#L20
type WaitGroup struct {
noCopy noCopy
// 64-bit value: high 32 bits are counter,
On Thursday, February 2, 2017 at 12:11:39 AM UTC+8, Jan Mercl wrote:
>
> On Wed, Feb 1, 2017 at 5:04 PM T L
> wrote:
>
> > But what does an allocated struct or slice means? A struct or slice
> allocated on heap, not stack?
>
> There's no heap nor stack from the POV of the
On Wed, Feb 1, 2017 at 5:04 PM T L wrote:
> But what does an allocated struct or slice means? A struct or slice
allocated on heap, not stack?
There's no heap nor stack from the POV of the language spec. Allocated
means appropriate amount of storage is now used by the
42 matches
Mail list logo