My results:
https://play.golang.org/p/o2cGAcpNMkX
I can't reproduce your results.
Peter
On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>
> package main
>
> import "testing"
>
> const N = 1615119
> // It is strange that if N is large enough,
> // the one line implementat
Indeed. I neglected to heed the comment I left expressly for this purpose.
:(
Thanks!
Andrew
On Friday, May 14, 2021 at 10:25:18 AM UTC-7 ksri...@gmail.com wrote:
> I applied your patch in-flight from your review,
> https://go-review.googlesource.com/c/go/+/319591/,
> and I am seeing other
I applied your patch in-flight from your review,
https://go-review.googlesource.com/c/go/+/319591/,
and I am seeing other failures. It appears we need to apply the ordering of
setgids to the following tests as well.
Also, I grepped around for the pattern syscall.Setgroups there are no
others I cou
On Friday, May 14, 2021 at 10:28:24 AM UTC-4 Michael Pratt wrote:
> Go has a non-moving GC [1], so that is not an issue.
>
It is my understanding that the go team has always explicitly maintained
the 'right' to change the GC to allow moving memory. Or to allow another
implementation of the Go
I don't think the current API provides that functionality.
In the original proposal for signal.NotifyContext, there were several
discussions, including related to what features the new API should provide.
The consensus was that if a user wants to make a decision base on the
signal caught, they
Go has a non-moving GC [1], so that is not an issue. That said,
unsafe.Pointer states "the referenced allocated object, if any, is retained
and not moved until the call completes". It doesn't say that this
recursively applies to objects referenced by the converted object, though I
perhaps it should
> You can use a *byte for the buffer. For instance, unix.Iovec does this
Are you sure that's not a bug? What's to stop the *Byte from being
moved by the GC?
On Fri, May 14, 2021 at 2:27 PM Michael Pratt wrote:
>
> You can use a *byte for the buffer. For instance, unix.Iovec does this:
> https:
You can use a *byte for the buffer. For instance, unix.Iovec does this:
https://pkg.go.dev/golang.org/x/sys/unix#Iovec
Users can cast a *unix.Iovec directly to unsafe.Pointer for Syscall without
any special handling of the *byte field.
On Fri, May 14, 2021, 09:01 sh...@tigera.io wrote:
> Now, i
Now, is it technically legal to convert a uintptr to some location that was
manually allocated and then cast it to an unsafe.Pointer? When I look at
the docs for unsafe.Pointer, I can't match that to any of the cases but it
seems very likely to be safe by analogy with the GCO rules for handling
Thanks for the pointer to that package; looking at our go.mod, looks like
we've already got it as a transitive dependency so it looks ideal for my
use case.
On Friday, May 14, 2021 at 12:10:45 PM UTC+1 Jan Mercl wrote:
> On Fri, May 14, 2021 at 12:36 PM sh...@tigera.io wrote:
>
> > One way I c
On Fri, May 14, 2021 at 12:36 PM sh...@tigera.io wrote:
> One way I could see to solve this would be to do some manual memory
> management with MMap or BRK to allocate the buffer but I wondered if there
> was an easier way?
IMO using manual memory management _is_ the easy way in this case. I'm
Hi all,
I'm looking for a safe way to make a unix syscall where the syscall takes a
pointer to a struct and, in turn, the struct needs to contain a pointer to
a buffer (for the kernel to read or write to).
According to the rules in the unsafe package, I don't think this is safe:
buf := [128]by
Hi all,
As per https://golang.org/issue/38968, approved nearly a year ago,
x/lint is now deprecated and its repository has been frozen.
There's no drop-in replacement to golint per se, but you should find
that https://staticcheck.io/ works well in encouraging good Go code,
much like golint did in
13 matches
Mail list logo
