[go-nuts] Re: Strange benchmark results

[peterGo]

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 implementations are fast as the others.
> // And if N is odd number, the InsertOneline_Disassemble
> // implementation is about 10% faster than the others.
>
> func init() {
> println(" N =", N)
> }
>
> func InsertOneline(s []int, k int, vs ...int) []int {
> return append(s[:k], append(vs, s[k:]...)...)
> }
>
> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
> z := append(vs, s[k:]...)
> return append(s[:k], z...)
> }
>
> func InsertVerbose(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, len(s) + len(vs))
> copy(s2, s[:k])
> copy(s2[k:], vs)
> copy(s2[k+len(vs):], s[k:])
> return s2
> }
>
>
> func InsertVerbose_b(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, 0, len(s) + len(vs))
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> func InsertVerbose_c(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> var s1 []int
> func Benchmark_InsertOneline(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/5
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1 = InsertOneline(x, k, y...)
> }
> }
>
> var s1b []int
> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1b = InsertOneline_Disassemble(x, k, y...)
> }
> }
>
> var s2 []int
> func Benchmark_InsertVerbose(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s2 = InsertVerbose(x, k, y...)
> }
> }
>
> var s3 []int
> func Benchmark_InsertVerbose_b(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s3 = InsertVerbose_b(x, k, y...)
> }
> }
>
> var s4 []int
> func Benchmark_InsertVerbose_c(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s4 = InsertVerbose_c(x, k, y...)
> }
> }
>
>
> The result:
>
> $ go test -bench=. -benchtime=3s
>  N = 1615119
> goos: linux
> goarch: amd64
> pkg: a.y/bench/sliceinsert
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> Benchmark_InsertOneline-4693   4741509 ns/op
> Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
> Benchmark_InsertVerbose-4764   4627334 ns/op
> Benchmark_InsertVerbose_b-4  769   4958537 ns/op
> Benchmark_InsertVerbose_c-4  661   4855514 ns/op
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3f202442-be5c-4e55-b2d7-6dd1bc443089n%40googlegroups.com.

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

['Andrew G. Morgan' via golang-nuts]

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 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 could see.
>
> Thanks
> Kumar
>
>
> % grep -i -r SetGroup misc/cgo/*
> misc/cgo/test/issue1435.go: {call: 
> "Setgroups([]int{0,1,2,3})", fn: func() error { return 
> syscall.Setgroups([]int{0, 1, 2, 3}) }, filter: "Groups:", expect: "\t0 1 2 
> 3"},
> misc/cgo/test/issue1435.go: {call: "Setgroups(nil)", fn: 
> func() error { return syscall.Setgroups(nil) }, filter: "Groups:", expect: 
> ""},
> misc/cgo/test/issue1435.go: {call: "Setgroups([]int{0})", fn: 
> func() error { return syscall.Setgroups([]int{0}) }, filter: "Groups:", 
> expect: "\t0"},
>
> # ../misc/cgo/test
> --- FAIL: Test1435 (0.01s)
> issue1435.go:181: [6] "Setgroups([]int{0,1,2,3})" comparison: 
> "/proc/29462/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
> [pid=29462 file:'Name: test.test
> Umask: 0022
> State: S (sleeping)
> Tgid: 29462
> Ngid: 0
> Pid: 29462
> PPid: 27896
> TracerPid: 0
> Uid: 0 0 0 0
> Gid: 0 0 0 0
> FDSize: 64
> Groups: 1 2 3 0 
> NStgid: 29462
> NSpid: 29462
> NSpgid: 9
> NSsid: 9
> VmPeak: 1215460 kB
> VmSize: 1191416 kB
> VmLck:   0 kB
> VmPin:   0 kB
> VmHWM:5848 kB
> VmRSS:5848 kB
> RssAnon:1724 kB
> RssFile:4124 kB
> RssShmem:   0 kB
> VmData:  194472 kB
> VmStk: 132 kB
> VmExe:1580 kB
> VmLib:1700 kB
> VmPTE: 156 kB
> VmSwap:   0 kB
> HugetlbPages:   0 kB
> CoreDumping: 0
> Threads: 12
> SigQ: 0/128577
> SigPnd: 
> ShdPnd: 
> SigBlk: fffc3bfa3a00
> SigIgn: 
> SigCgt: fffdffc1feff
> CapInh: a80425fb
> CapPrm: a80425fb
> CapEff: a80425fb
> CapBnd: a80425fb
> CapAmb: 
> NoNewPrivs: 0
> Seccomp: 2
> Speculation_Store_Bypass: thread force mitigated
> Cpus_allowed: ff
> Cpus_allowed_list: 0-7
> Mems_allowed: 
> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
> Mems_allowed_list: 0
> voluntary_ctxt_switches: 19
> nonvoluntary_ctxt_switches: 0
> ' Pid: 29462]
> FAIL
> exit status 1
> FAIL misc/cgo/test 6.853s
> 2021/05/14 16:53:14 Failed: exit status 1
> --- FAIL: Test1435 (0.01s)
> issue1435.go:181: [6] "Setgroups([]int{0,1,2,3})" comparison: 
> "/proc/29422/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
> [pid=29422 file:'Name: test.test
> Umask: 0022
> State: S (sleeping)
> Tgid: 29422
> Ngid: 0
> Pid: 29422
> PPid: 27897
> TracerPid: 0
> Uid: 0 0 0 0
> Gid: 0 0 0 0
> FDSize: 64
> Groups: 1 2 3 0 
> NStgid: 29422
> NSpid: 29422
> NSpgid: 9
> NSsid: 9
> VmPeak: 1215712 kB
> VmSize: 1192820 kB
> VmLck:   0 kB
> VmPin:   0 kB
> VmHWM:5104 kB
> VmRSS:5104 kB
> RssAnon:1464 kB
> RssFile:3640 kB
> RssShmem:   0 kB
> VmData:  195880 kB
> VmStk: 132 kB
> VmExe:1556 kB
> VmLib:1728 kB
> VmPTE: 176 kB
> VmSwap:   0 kB
> HugetlbPages:   0 kB
> CoreDumping: 0
> Threads: 12
> SigQ: 0/128577
> SigPnd: 
> ShdPnd: 
> SigBlk: fffc3bfa3a00
> SigIgn: 
> SigCgt: fffdffc1feff
> CapInh: a80425fb
> CapPrm: a80425fb
> CapEff: a80425fb
> CapBnd: a80425fb
> CapAmb: 
> NoNewPrivs: 0
> Seccomp: 2
> Speculation_Store_Bypass: thread force mitigated
> Cpus_allowed: ff
> Cpus_allowed_list: 0-7
> Mems_allowed: 
> 

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

[Kumar Srinivasan]

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

Thanks
Kumar


% grep -i -r SetGroup misc/cgo/*
misc/cgo/test/issue1435.go: {call: "Setgroups([]int{0,1,2,3})",
fn: func() error { return syscall.Setgroups([]int{0, 1, 2, 3}) }, filter:
"Groups:", expect: "\t0 1 2 3"},
misc/cgo/test/issue1435.go: {call: "Setgroups(nil)", fn: func()
error { return syscall.Setgroups(nil) }, filter: "Groups:", expect: ""},
misc/cgo/test/issue1435.go: {call: "Setgroups([]int{0})", fn:
func() error { return syscall.Setgroups([]int{0}) }, filter: "Groups:",
expect: "\t0"},

# ../misc/cgo/test
--- FAIL: Test1435 (0.01s)
issue1435.go:181: [6] "Setgroups([]int{0,1,2,3})" comparison:
"/proc/29462/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad)
[pid=29462 file:'Name: test.test
Umask: 0022
State: S (sleeping)
Tgid: 29462
Ngid: 0
Pid: 29462
PPid: 27896
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 64
Groups: 1 2 3 0
NStgid: 29462
NSpid: 29462
NSpgid: 9
NSsid: 9
VmPeak: 1215460 kB
VmSize: 1191416 kB
VmLck:   0 kB
VmPin:   0 kB
VmHWM:5848 kB
VmRSS:5848 kB
RssAnon:1724 kB
RssFile:4124 kB
RssShmem:   0 kB
VmData:  194472 kB
VmStk: 132 kB
VmExe:1580 kB
VmLib:1700 kB
VmPTE: 156 kB
VmSwap:   0 kB
HugetlbPages:   0 kB
CoreDumping: 0
Threads: 12
SigQ: 0/128577
SigPnd: 
ShdPnd: 
SigBlk: fffc3bfa3a00
SigIgn: 
SigCgt: fffdffc1feff
CapInh: a80425fb
CapPrm: a80425fb
CapEff: a80425fb
CapBnd: a80425fb
CapAmb: 
NoNewPrivs: 0
Seccomp: 2
Speculation_Store_Bypass: thread force mitigated
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed:
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
Mems_allowed_list: 0
voluntary_ctxt_switches: 19
nonvoluntary_ctxt_switches: 0
' Pid: 29462]
FAIL
exit status 1
FAIL misc/cgo/test 6.853s
2021/05/14 16:53:14 Failed: exit status 1
--- FAIL: Test1435 (0.01s)
issue1435.go:181: [6] "Setgroups([]int{0,1,2,3})" comparison:
"/proc/29422/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad)
[pid=29422 file:'Name: test.test
Umask: 0022
State: S (sleeping)
Tgid: 29422
Ngid: 0
Pid: 29422
PPid: 27897
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 64
Groups: 1 2 3 0
NStgid: 29422
NSpid: 29422
NSpgid: 9
NSsid: 9
VmPeak: 1215712 kB
VmSize: 1192820 kB
VmLck:   0 kB
VmPin:   0 kB
VmHWM:5104 kB
VmRSS:5104 kB
RssAnon:1464 kB
RssFile:3640 kB
RssShmem:   0 kB
VmData:  195880 kB
VmStk: 132 kB
VmExe:1556 kB
VmLib:1728 kB
VmPTE: 176 kB
VmSwap:   0 kB
HugetlbPages:   0 kB
CoreDumping: 0
Threads: 12
SigQ: 0/128577
SigPnd: 
ShdPnd: 
SigBlk: fffc3bfa3a00
SigIgn: 
SigCgt: fffdffc1feff
CapInh: a80425fb
CapPrm: a80425fb
CapEff: a80425fb
CapBnd: a80425fb
CapAmb: 
NoNewPrivs: 0
Seccomp: 2
Speculation_Store_Bypass: thread force mitigated
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed:
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
Mems_allowed_list: 0
voluntary_ctxt_switches: 19
nonvoluntary_ctxt_switches: 4
' Pid: 29422]
FAIL
exit status 1
FAIL misc/cgo/test 6.429s
2021/05/14 16:53:15 Failed: exit status 1
--- FAIL: Test1435 (0.02s)
issue1435.go:181: [6] "Setgroups([]int{0,1,2,3})" comparison:

Re: [go-nuts] Syscalls that take structs with embedded pointers

[jake...@gmail.com]

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 language to do so. That is the purpose of some of 
these rules. So if you write code that assumes a non-moving GC, then be 
prepared for breakage later. 

I know that the standard libraries do things that violate those rules, 
because they are tied to the Go version they ship with. So the Go team will 
adjust them as necessary when changes are made to Go. I am not entirely 
clear if this logic applies to the  golang.org/x libraries as well. 
 
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2df2d684-0c12-4697-ab9e-568bf97870c1n%40googlegroups.com.

[go-nuts] Re: signal.NotifyContext - Does it expose the signal handled?

[Vladimir Varankin]

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 should use "signal.Notify", as the low-level API, which 
allows that (refer to this issue https://github.com/golang/go/issues/37255).

On Thursday, May 13, 2021 at 10:54:39 PM UTC+2 amits...@gmail.com wrote:

> Hi - i took a brief look and it doesn't look like we can access the
> signal that was handled via the signal.NotifyContext() function call?
> It could be useful for logging messages.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b7b21dd2-b12a-4a01-b2f0-3dee10778cd1n%40googlegroups.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

['Michael Pratt' via golang-nuts]

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.

[1] Except for stacks, but taking the address of a byte slice and putting
it in Iovec.Base will force it to escape anyways.

On Fri, May 14, 2021 at 9:44 AM Shaun Crampton  wrote:

> > 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://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, 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
> "C" pointers and "Go" pointers.
> >>
> >> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:
> >>>
> >>> 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 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
>  using https://pkg.go.dev/modernc.org/memory for this.
> >>
> >> --
> >> 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.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/317d44cf-8f2b-42d6-ab10-b42da7280616n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoThU8Qe8p1XyycwcoHnAcXG46DXYKWvDhLSUakAKN7fYmwHA%40mail.gmail.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

[Shaun Crampton]

> 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://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, 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 "C" 
>> pointers and "Go" pointers.
>>
>> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:
>>>
>>> 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 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
 using https://pkg.go.dev/modernc.org/memory for this.
>>
>> --
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/317d44cf-8f2b-42d6-ab10-b42da7280616n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMhR0U2_QWLimoS0GJtwHCjFyJt-0qct3n-N%2BP98n-wdjeZPYw%40mail.gmail.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

['Michael Pratt' via golang-nuts]

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, 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
> "C" pointers and "Go" pointers.
>
> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:
>
>> 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 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
>>> using https://pkg.go.dev/modernc.org/memory for this.
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/317d44cf-8f2b-42d6-ab10-b42da7280616n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoThU-Ph1vE%3DgAPLGtD76aBHU6bgxxuquf_3E7c__9dm0UH1A%40mail.gmail.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

[sh...@tigera.io]

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 "C" 
pointers and "Go" pointers.

On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:

> 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 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
>> using https://pkg.go.dev/modernc.org/memory for this.
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/317d44cf-8f2b-42d6-ab10-b42da7280616n%40googlegroups.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

[sh...@tigera.io]

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 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
> using https://pkg.go.dev/modernc.org/memory for this.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0200d7fb-a399-418a-8bbb-fcbbdbe9d28bn%40googlegroups.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

[Jan Mercl]

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
using https://pkg.go.dev/modernc.org/memory for this.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XOHhfj6wLike0RegHC6S%2BVzRCh7fOpJ%2B9No7B1hn7ijQ%40mail.gmail.com.

[go-nuts] Syscalls that take structs with embedded pointers

[sh...@tigera.io]

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]byte{}
wrapper := someStruct{buf: }
... := unix.Syscall(trap, uintptr(unsafe.Pointer()), ...)

The point to "wrapper" is protect from being moved by unsafe.Pointer's 
"Conversion of a Pointer to a uintptr when calling syscall.Syscall" rule 
but I think the pointer to buf within that struct is not safe from being 
rewritten.

Lots of ioctls use this pattern as does the BPF syscall.  At the moment, 
we're resorting to CGo to make those calls but it'd be nice to get rid of 
that.

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?

Cheers,
-Shaun

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1c41cd4e-6d54-43bd-98eb-b53cd9ca5598n%40googlegroups.com.

[go-nuts] x/lint (golint) is now deprecated and frozen

['Daniel Martí' via golang-nuts]

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 the past, since it also includes style checks.
There's always "gofmt" and "go vet" too, of course.

If you're currently enforcing golint via CI, hooks, or checks, it's
recommended that you stop doing that. golint was never intended as a
tool with zero false positives, and it hasn't been actively maintained
for some time.

Thanks.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210514083101.ulgafmvot4gqycvt%40carbon.localhost.