Re: [go-nuts] using runtime cgo.Handle passing struct types
On Thu, May 16, 2024 at 12:57 AM Pavan wrote:
>
> Thanks . Yes it works when C API takes uintptr_t. In my case, the C API
> expects void * which i can not change, so I was trying to make it work with
> the variant example stated above.
In C, unlike Go, you can convert between void* and uintptr_t. When
using cgo, one approach is a little wrapper function in the cgo
comment that takes a uintptr_t and calls the real function with a
conversion to void*.
Ian
> On Thursday, May 16, 2024 at 5:28:55 AM UTC+5:30 Ian Lance Taylor wrote:
>>
>> On Tue, May 14, 2024 at 10:37 PM Pavan wrote:
>> >
>> > I need to pass value of struct type, which has C strings and functions to
>> > C function as void* argument. C layer would provide this struct type data
>> > back to go function. Below is the sample program. It panics if the handle
>> > used is returned from getH function. It works fine if the handle is
>> > global. Can the handle be dynamically returned from getH and make it work.
>> > Please correct if i missed something..
>> >
>> >
>> >
>> > package main
>> >
>> > /*
>> > struct dt {
>> > void *context;
>> > };
>> > typedef struct dt dt;
>> >
>> > extern void MyGoPrint(void *context);
>> > static inline void myprint(struct dt *a1) {
>> > MyGoPrint(a1->context);
>> > }
>> > */
>> > import "C"
>> > import (
>> > "context"
>> > "runtime/cgo"
>> > "unsafe"
>> > )
>> >
>> > //export MyGoPrint
>> > func MyGoPrint(context unsafe.Pointer) {
>> > h := *(*cgo.Handle)(context)
>> > val := h.Value().(accessTokenCB)
>> > println(val.id)
>> > h.Delete()
>> > }
>> >
>> > type At struct {
>> > Tok string
>> > }
>> >
>> > type accessTokenCB struct {
>> > ctx context.Context
>> > callback func(context.Context, *At) error
>> > id uint64
>> > ctoken *C.char
>> > cprivateKey *C.char
>> > }
>> >
>> > func getH() cgo.Handle {
>> > cb := func(ctx context.Context, tok *At) error {
>> > tok.Tok = "123"
>> > return nil
>> > }
>> > val := accessTokenCB{callback: cb, ctx: context.Background(), id: 32,
>> > ctoken: nil, cprivateKey: nil}
>> > h := cgo.NewHandle(val)
>> > return h
>> >
>> > }
>> >
>> > var h cgo.Handle
>> >
>> > func main() {
>> > var h cgo.Handle // commenting this line runs the program successfully
>> > else it panics. (cgo argument has Go pointer to unpinned Go pointer)
>> > h = getH()
>> > var poolCt C.dt
>> > poolCt.context = unsafe.Pointer()
>> > C.myprint()
>> > // Output: 32
>> > }
>>
>> You aren't following the pattern shown at
>> https://pkg.go.dev/runtime/cgo#Handle. Pass the cgo.Handle value to C
>> code, not the address of the cgo.Handle value. Catch the cgo.Handle
>> value as a uintptr_t in C. The point of using cgo.Handle is to avoid
>> difficulties passing pointers between Go and C. When you pass a
>> pointer to a cgo.Handle, you just get those difficulties back again.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/39afbb8b-8361-40a2-967f-0f462ef45994n%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/CAOyqgcXiL6%2Bm_HtF0SYuExy2Bu9_o%2B3pVAt-FCG3WX05zUOb1A%40mail.gmail.com.
Re: [go-nuts] using runtime cgo.Handle passing struct types
On Tue, May 14, 2024 at 10:37 PM Pavan wrote:
>
> I need to pass value of struct type, which has C strings and functions to C
> function as void* argument. C layer would provide this struct type data back
> to go function. Below is the sample program. It panics if the handle used is
> returned from getH function. It works fine if the handle is global. Can the
> handle be dynamically returned from getH and make it work. Please correct if
> i missed something..
>
>
>
> package main
>
> /*
> struct dt {
> void *context;
> };
> typedef struct dt dt;
>
> extern void MyGoPrint(void *context);
> static inline void myprint(struct dt *a1) {
> MyGoPrint(a1->context);
> }
> */
> import "C"
> import (
> "context"
> "runtime/cgo"
> "unsafe"
> )
>
> //export MyGoPrint
> func MyGoPrint(context unsafe.Pointer) {
> h := *(*cgo.Handle)(context)
> val := h.Value().(accessTokenCB)
> println(val.id)
> h.Delete()
> }
>
> type At struct {
> Tok string
> }
>
> type accessTokenCB struct {
> ctx context.Context
> callbackfunc(context.Context, *At) error
> id uint64
> ctoken *C.char
> cprivateKey *C.char
> }
>
> func getH() cgo.Handle {
> cb := func(ctx context.Context, tok *At) error {
> tok.Tok = "123"
> return nil
> }
> val := accessTokenCB{callback: cb, ctx: context.Background(), id: 32, ctoken:
> nil, cprivateKey: nil}
> h := cgo.NewHandle(val)
> return h
>
> }
>
> var h cgo.Handle
>
> func main() {
> var h cgo.Handle // commenting this line runs the program successfully else
> it panics. (cgo argument has Go pointer to unpinned Go pointer)
> h = getH()
> var poolCt C.dt
> poolCt.context = unsafe.Pointer()
> C.myprint()
> // Output: 32
> }
You aren't following the pattern shown at
https://pkg.go.dev/runtime/cgo#Handle. Pass the cgo.Handle value to C
code, not the address of the cgo.Handle value. Catch the cgo.Handle
value as a uintptr_t in C. The point of using cgo.Handle is to avoid
difficulties passing pointers between Go and C. When you pass a
pointer to a cgo.Handle, you just get those difficulties back again.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXthcBN6-NP4n1ihCU2HW1YSwNSDdEd0QDft_SP6ULBHw%40mail.gmail.com.
Re: [go-nuts] Permissions in ~/go/pkg
On Fri, May 10, 2024 at 2:11 PM Tobias Klausmann wrote: > > On Fri, 10 May 2024, Ian Lance Taylor wrote: > > This is a choice made by Go. You can override with the -modcacherw > > option to "go build", "go test", "go install", and similar code. You > > can make that option the default by setting GOFLAGS in the environment > > or via "go env GOFLAGS=...". > > > > You can also remove the module cache using "go clean -modcache". > > Thanks for the explanation! What is the rationale for the read-only > perms, though? It's essential for supply chain security that builds with a specific version of a package always use the same code. It's natural for debugging for people to look at the source code in the module cache. Making that source code read-only removes a class of accidents in which somebody looking at the code in the module cache modifies it, without necessarily realizing that that will affect all builds on that machine that use that package. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX7x39RKShv%2ByJBt%3DztoQWs1MO%3DcZqiseDtXrsvjBNV3g%40mail.gmail.com.
Re: [go-nuts] Permissions in ~/go/pkg
On Fri, May 10, 2024 at 10:43 AM Tobias Klausmann wrote: > > I test and try a whole load of Go tools and libraries, and as a result, > my ~go/pkg dir quickly grows. While I'd love some kind of automatic > expiry for that cache, I am fine with just occasionally running rm-rf on > that dir myself. > > ... except it doesn't work. For some unclear reason, some of those > directories and files are created with readonly permissions: > > ``` > $ rm -rf go/pkg > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/.gitattributes': > Permission denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/.gitignore': Permission > denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/LICENSE': Permission > denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/README.md': Permission > denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/bmp-string.go': > Permission denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/bmp-string_test.go': > Permission denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/crypto.go': Permission > denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/crypto_test.go': > Permission denied > rm: cannot remove > 'go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/errors.go': Permission > denied > [... lots more elided ...] > $ stat go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/errors.go > File: go/pkg/mod/software.sslmate.com/src/go-pkcs12@v0.2.0/errors.go > Size: 751 Blocks: 8 IO Block: 4096 regular file > Device: 0,36Inode: 7317588 Links: 1 > Access: (0444/-r--r--r--) Uid: ( 1000/klausman) Gid: ( 1000/klausman) > Access: 2024-04-04 11:04:37.367542592 +0200 > Modify: 2024-04-04 11:04:37.367542592 +0200 > Change: 2024-04-04 11:04:37.367542592 +0200 > Birth: 2024-04-04 11:04:37.367542592 +0200 > $ > ``` > > Needless to say, this is annoying, and while I can 'fix' it by doing a > find|xargs chmod, I'd rather the permissions weren't this restrictive in > the first place. > > So I wonder why they look like that. Is it a umask issue? Or something > in git's config? Or is Go at fault here? This is a choice made by Go. You can override with the -modcacherw option to "go build", "go test", "go install", and similar code. You can make that option the default by setting GOFLAGS in the environment or via "go env GOFLAGS=...". You can also remove the module cache using "go clean -modcache". 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVAikLCXX0UAqhtK%3D5%3D2hqwkEQ%2BZSJhkhHg6EOTZ3a%2BXQ%40mail.gmail.com.
Re: [go-nuts] just started using modules, what have i missed? (continuation..)
On Mon, May 6, 2024 at 9:40 AM 'simon place' via golang-nuts wrote: > > OK, i had thought, (without understanding why), you can't/don't install > non-main packages, as the error message says. ( as mentioned in previous post) > > simon@fedora:~$ go install github.com/vulkan-go/vulkan@latest > package github.com/vulkan-go/vulkan is not a main package > > but it works sometimes? (still error message) > > simon@fedora:~$ go install github.com/xyproto/png2svg@latest > go: downloading github.com/xyproto/png2svg v1.5.4 > go: downloading github.com/xyproto/tinysvg v1.1.0 > package github.com/xyproto/png2svg is not a main package > > and why not install the latest if not specified anyway? It didn't work either time. In the second case it just did some other stuff before noticing. Before modules, it made sense to "go install" a non-main package: that would build the package and set it up to be imported by other packages. With modules, though, it doesn't make any sense. The go.mod file specifies exactly what version of a non-main package to use. And the compiled form of packages is stored in the package cache. Installing a non-main package isn't going to affect how anything else is built. For a while it was available essentially a no-op. Now it gets an error. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWzX5OkMXz_i7aSf7QXZagY1daDv4FpQa17d4XZv4Yniw%40mail.gmail.com.
Re: [go-nuts] Unused local constants not a compiler error
On Thu, May 2, 2024 at 2:48 PM will@gmail.com wrote: > > Was this always the case? Is this a bug? Seems like it should be a compiler > error, like unused local variables. Yes, it's always been the case. It would probably be painful to change it now. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXgYXom03QxEFXgdOf3xJGtQto5_8PbQaCG9TDLQynTdA%40mail.gmail.com.
Re: [go-nuts] understanding garbage collection logging
On Thu, May 2, 2024 at 12:48 PM Doug Whitfield wrote: > > I come from java-land, and am having some trouble figuring out gc logging in > go. I have been asked to contribute to a memory leak issue in Minio, which is > written in Go. The first way to try to rack down a memory leak is heap profiling. For example see https://go.dev/blog/pprof, the section on -memprofile. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXLx1Nqfv1CmzE4iP_WXpCn46sbDUtAYEbacqSD4OCogA%40mail.gmail.com.
Re: [go-nuts] loading Directives for ptest and pxtest
On Wed, May 1, 2024 at 2:36 PM Menno van Rahden wrote: > > Hello, I'm trying to tweak the Go stdlib test cmd a bit to support certain > directives, but hitting some resistance. > > I'd like to understand why the `load.Package.Internal.Build` instances for > `ptest` and `pxtest` (see: > https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/test/test.go;drc=0159150a4aa0b10f9845af94726cd67ffee93b75;l=) > don't contain the Directives, even though the fields > `load.Package.[EmbedPatterns|TestEmbedPatterns|XTestEmbedPatterns]` are > populated correctly. > Print-out the values for embed patterns and Directives. > > Reproducing this is pretty simple: > Create a project with a package with a test file and a test-package file (for > xtest). Add random directives (e.g. `//go:generate echo "hello world"` and > `//go embed `) and execute the tests with the freshly built binary. > > Does anybody by any change know how to achieve that these fields are set > consistently and can lead me in the right direction? I haven't tried, but I would expect to find them in the TestDirectives and XTestDirectives fields. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUG%3D7s7QpGvbqzoz9huprArVuJ2wR-O9DyBStdJ_mjYpg%40mail.gmail.com.
Re: [go-nuts] tuples! tuples! tuples!
On Sun, Apr 28, 2024 at 4:10 AM Andrew Harris wrote:
>
> 1. Tuple types
> Outside of generics, tuple type syntax requires named fields.
>
> TupleType = "(" { IdentifierList Type [ ", " ] } ")" .
>
> // e.g.:
> type Point (X, Y int)
>
> More irregularly, the TupleType syntax is used exclusively to declare named
> types, and these named tuple types cannot implement methods. As a result, a
> named tuple type is entirely defined at the site of the type definition.
Thanks for writing this up.
This part of what you wrote seems too similar to a struct. I don't
know whether we will ever add tuples to Go, but I'm certain that if we
add them they must be clearly distinct from structs. If people ever
start wondering "should I use a struct or should I use a tuple," then
we have failed. One of the goals of Go is that it should be a simple
language. One of the characteristics of a simple language is that
people spend their time writing code. They don't spend their time
considering which aspects of a language to use and how.
Go is also intended to be an orthogonal language. That means that a
concept should apply wherever it is meaningful. In particular, in Go,
any named type should be permitted to have methods. To add a
restriction saying that certain kinds of types can't have methods is
to complicate the language and means that people have more to
remember.
Thanks.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWuiBPhj%3D8wsXWXRKz6%2BdW%3D1jdLQObkc93GOiY5Hwg_3Q%40mail.gmail.com.
Re: [go-nuts] time.ParseDuration does not accept scientific notation
On Fri, Apr 26, 2024 at 3:39 PM Scott Pakin wrote: > > While parsing output from some third-party program, I discovered that > time.ParseDuration does not accept inputs expressed in scientific notation > even though strconv.ParseFloat does accept such inputs. Here’s an playground > example demonstrating this limitation: https://go.dev/play/p/G-1FveHxpZ3. > > Any chance ParseDuration could be enhanced to accept the same numerical > values as ParseFloat? The first step would be to open a proposal for this change. See https://github.com/golang/proposal#readme. Thanks. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXGQPCBJN%3D-yK7qDmKTUfcLUHsO-Sd4Cj81ub-uWAVVaw%40mail.gmail.com.
Re: [go-nuts] generics question
On Mon, Apr 22, 2024 at 11:01 PM Jochen Voss wrote: > > This works, see my code below. Followup question: is there a way to refer to > the new type without having to list both the element type and the pointer > type separately? Unfortunately there is not. At some point in the future the language may support type inference for type arguments to types, for cases where one type argument can be inferred from another type argument. Currently that is not supported because there are some complex issues involving cyclical types that need to be resolved or side-stepped. In Go 1.23 I think it should be possible to simplify using these kinds of types with a type alias as in "type X[E] = C[E, *E]". 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXbJXirak2J1GF8Rx0zUvyTXXvwrFZ-RBPd7Jxk5iUe3g%40mail.gmail.com.
Re: [go-nuts] generics question
On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss wrote:
>
> Using generics, can I somehow write a constraint which says that *T (instead
> of T) implements a certain interface? The following code illustrated what
> I'm trying to do:
>
> type A int
>
> func (a *A) Set(x int) {
> *a = A(x)
> }
>
> type B string
>
> func (b *B) Set(x int) {
> *b = B(strconv.Itoa(x))
> }
>
> type C1 struct {
> Val []A
> }
>
> func (c *C1) Set(v int) {
> for i := range c.Val {
> c.Val[i].Set(v)
> }
> }
>
> type C2 struct {
> Val []B
> }
>
> func (c *C2) Set(v int) {
> for i := range c.Val {
> c.Val[i].Set(v)
> }
> }
>
> I would like to use generics to use a single definition for the methods which
> here are func (c *C1) Set(v int) and func (c *C2) Set(v int). (My real code
> has many base types, instead of just A and B.) How can I do this?
>
> I tried the naive approach:
>
> type C[T interface{ Set(int) }] struct {
> Val []T
> }
>
> but when I try to use the type C[A] now, I get the error message "A does not
> satisfy interface{Set(int)} (method Set has pointer receiver)".
type C[P interface {
*E
Set(int)
}, E any] struct {
Val []P
}
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXSqw6JOmNrjyJ1KWn9MB3p%2BDYUooC0byRP%2BqB0x7jpHg%40mail.gmail.com.
Re: [go-nuts] error : undefined: app.NewWindow
On Mon, Apr 22, 2024 at 10:54 AM AndyPeng wrote: > > Imported the "gioui.org/app" package,but got an error when compiling: > undefined: app.NewWindow. Please tell us exactly what you did and exactly what happened. Show us the code. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX9fwrqAM-ck_AYWYz3qc-j3hxzgJtyaHOGZFL-P1VM4g%40mail.gmail.com.
Re: [go-nuts] compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http package
On Sat, Apr 20, 2024 at 7:34 PM Ron Hermsen wrote: > > compiling go-1.22.2 and go-1.21.9 fail due to timeout during test of net/http > package > > I tried a number of earlier releases but looks only the latest two fail. > (each build takes about 40min, so didn't try more options) > > > ok net 8.598s > panic: test timed out after 9m0s > running tests: > > FAILnet/http540.260s > > FAIL > go tool dist: Failed: exit status 1 > > > system details: > TinyCoreLinux, CorePlus64-15.0 > > $ uname -a > Linux testapps 6.6.8-tinycore64 #666 SMP Sat Dec 23 16:41:21 UTC 2023 x86_64 > GNU/Linux > > Both source version and the bootstrap are 1.22.2 (or both are 1.21.9). > > Tried source version 1.22.2 and bootstrap version 1.22.0 which failed the > net/http package the same way. I don't know why the tests are taking so long on your system, but your Go distribution is installed and working. It is only failing during the testing phase. To explore what is happening with net/http, try running "go test -test.short -test.v net/http". On my laptop it takes just a few seconds. Using -test.v may show which test is hanging. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWhdXE%3DhC5RHyTfsnJ3PqPwpqqjetwDrKZKpTE%3DptjruA%40mail.gmail.com.
Re: [go-nuts] TestCopyNWriteTo
On Sun, Apr 14, 2024 at 8:05 PM Stephen wrote: > > https://github.com/golang/go/blob/c0a0ba254c48fc855f9501b0bd3b78e6847ca923/src/io/io_test.go#L167 > > I was walking through this code, and it didn't seem to hit [WriteTo] > (https://github.com/golang/go/blob/c0a0ba254c48fc855f9501b0bd3b78e6847ca923/src/io/io.go#L410-L412) > because of LimitReader > > Is this intended behavior? The purpose of the test is to make sure that CopyN does the correct thing even if the source type implements WriteTo. So, yes, this is intended behavior. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXL%3DctU1qa%3DjdVpFudSEfGcH3aTt-c860mjoiyeEOBWnA%40mail.gmail.com.
Re: [go-nuts] Is it possible to "extract" the generic [T] from a reflected type ?
On Tue, Apr 9, 2024 at 9:41 AM Mihai Barbu wrote:
>
> I need to call some generic functions with types that are now known at
> compile time. Is it possible to do this?
> See the code below (vastly reduced).
>
> // fv is a function that returns an unknown type
> func Do(fv reflect.Value){
> // get the first returned type by function fv
> vt := fv.Type().Out(0)
>// how to call `Hello` with `v` ?
> // Obviously the code below is incorrect
> Hello[vt]()
> }
>
> func Hello[T any](){
> // do something with T
> json.Marshal(new(T))
> }
This is not possible. Sorry.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVTE26WbM7UsLtuyHNvOSmELMf1ZMgVt%3DycwFq9K4o3uQ%40mail.gmail.com.
Re: [go-nuts] Failure in file seek
On Mon, Apr 8, 2024, 3:33 PM Nikhilesh Susarla wrote: > I wanted to seek around a file by opening it using read-only, but then I > get this error called "Invalid argument" > > https://go-review.googlesource.com/c/go/+/14881 > > I read the above link and they say it is not supported to seek around. I > tried direct lseek in c language and it failed with same. > > Is there any way ? > What that link says is that if you open the file with O_APPEND then you can't Seek. Are you opening with O_APPEND? If not you will need to provide more information, such as a small program that demonstrates the problem. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV21eomhHpPGAVBFdu-WsyOp%3DX4LN_Z0v3n_i4a0qjbzw%40mail.gmail.com.
Re: [go-nuts] user process instruction pointer symbol lookup
On Tue, Apr 2, 2024 at 2:35 AM 'TheDiveO' via golang-nuts wrote: > > On Linux, given an arbitrary binary executable with symbol information in the > executable, how can I lookup an instruction pointer address to get the > corresponding symbol name? > > The binary (and its process) isn't a Go binary, but any arbitrary executable. > The stack unwinding has already been done, so I'm presented with a list of > instruction pointer addresses (return addresses) which I need to convert to > more useful symbol names. > > I've seen the stdlib's debug/elf package, but I lack the ELF knowledge to > press the elf package's knobs in the right order. Any examples of how to use > debug/elf, and is it even the right package to use in this case? debug/elf is the package to use. You'll want to call the Symbols method and look through the Symbols for one whose Value is <= the PC you want while Value+Size is > the PC you want. If you are looking at runtime PC's from a stack trace, be aware that on most systems these days programs are position-independent, so there will be an offset between the addresses in the binary and the addresses from the stack trace. I don't know offhand of a standard way to figure out that offset. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXQeaz_HuwDbrBdLmwOaL4XP2aig21118Woy8dDv_21mA%40mail.gmail.com.
Re: [go-nuts] Re: <-ctx.Done() panic - link injecting bot?
On Sat, Mar 30, 2024 at 3:21 AM Steven Hartland wrote: > > Johans account looks like a bot designed to inject links, possibly malicious, > is there an admin who can investigate and take the appropriate action? Thanks for pointing that out. I think I've banned them. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUAmKLduKvuKreCiY8YM%3D5A7BBy8tnCiA2qg6RjdsfSTQ%40mail.gmail.com.
Re: [go-nuts] GO111MODULE=off go get deprecated?
On Sat, Mar 23, 2024 at 12:20 PM Jeffery Carr wrote: > > While doing that and looking at the code, there are lots of interesting and > good things in internal/ that can't be used. While I think I understand the > reasons for internal/, I wonder if the GO compiler might be more immune to > those normal reasons. In general: it's sage advice to never make the compiler > people unhappy. Usually then lots of strange things start not working! > > In that regard, s/internal/workshop/ would denote things not yet stable. The > compiler really only needing an example to demonstrate the usage Our experience is that once something becomes publicly accessible, it becomes very difficult to change. It's already difficult to change runtime internal functions, because packages out there reach into the runtime using //go:linkname directives. This is clearly and obviously unsupported. Yet people do it. That forces us into the uncomfortable position of breaking existing working packages or advancing the runtime. It's not a great position to be in. That's why we have rules like internal packages that are difficult to break. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXOOtc-yacPu%3DcOVF9_jB9Ey38OowKHsyJFkX%3DtdoCpjg%40mail.gmail.com.
Re: [go-nuts] New goroutine to immediately acquire the lock when Lock in starving mode?
On Sat, Mar 23, 2024 at 11:58 AM Wen Wei wrote:
>
> Lock always calls runtime_SemacquireMutex(, queueLifo, 1) ->
> semacquire1 when in starving mode.
>
> ```go
> // src/runtime/sema.go
> func semacquire1(addr *uint32, lifo bool, profile semaProfileFlags,
> skipframes int, reason waitReason) {
> gp := getg()
> if gp != gp.m.curg {
> throw("semacquire not on the G stack")
> }
>
> // Easy case.
> if cansemacquire(addr) {
> return
> }
>
> // ...
> }
>
> func semrelease1(addr *uint32, handoff bool, skipframes int) {
> root := semtable.rootFor(addr)
> atomic.Xadd(addr, 1) // The semaphore released here may be immediately
> contended for by goroutines of other threads calling semacquire1.
> }
> ```
>
> Does a new goroutine immediately acquire the lock instead of queuing fairly
> when in starving mode?
It does seem possible.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV7KUfBVDGOx4Rwu7qHaZgGcMOMMb_y7%2BoiDTAKo2f_eA%40mail.gmail.com.
Re: [go-nuts] go vet not erroring waitgroup inc used after done
On Mon, Mar 25, 2024 at 12:46 PM Nikhilesh Susarla wrote: > > Why isn't go vet complaining that wg.Add is happening after the usage. Where > as the document clearly says increment and then use it as the wg.Done may be > called an can run into negative/deadlock First, please send Go code as plain text or as a link to the Go playground. The background on the text you sent makes it difficult to read. Thanks. To answer your question, vet doesn't check for any possible error condition. As described at https://cs.opensource.google/go/go/+/refs/tags/go1.22.1:src/cmd/vet/README, vet checks for mistakes that are, among other things, common. I'm not sure the mistake you describe is common. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVjFsXnVjoTv_fyB7SYmwPrFhCg8su4hU-NGw5kS2YhFQ%40mail.gmail.com.
Re: [go-nuts] Discussion on runtime/compiler meeting: Struct packing/reordering
On Thu, Mar 21, 2024 at 4:47 PM محمد بومنذر
wrote:
>
> I have been following the Go Runtime and Compiler team meeting notes for a
> while. In the recent notes, I noticed something that got my attention
> regarding memory layout optimization for structures.
> https://github.com/golang/go/issues/43930#issuecomment-2009816508
>
> I'm working on some code that interfaces with C libraries without directly
> utilizing the CGo tool (for portability reasons). Currently, I'm adding
> padding fields manually for C structs like
> struct {a int32; _ [4]byte}
>
> Would this behavior be affected?
Exactly because of this concern there is a proposal https://go.dev/issue/66408.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVvNcm-ojeG7gt1O47UpcZK2be3k13WfrnSbO5ZpLvcTg%40mail.gmail.com.
Re: [go-nuts] io.Reader can return (n, err), both non-zero
On Tue, Mar 19, 2024 at 6:40 PM Nigel Tao wrote:
>
> The ubiquitous io.Reader interface's Read method returns a (int,
> error). Surprisingly (for programmers coming from other languages with
> a built-in or idiomatic Result type), it's possible for both
> return values to be non-zero. There's (often overlooked??) commentary
> in https://pkg.go.dev/io#Reader that says:
>
> > Callers should always process the n > 0 bytes returned before considering
> > the error err.
>
> So that (again, especially for programmers used to saying result? or
> "try result" or similar Result aware mechanisms in other
> languages), the following Go code is incorrect:
>
> n, err := r.Read(buffer, etc)
> if err != nil {
> return err
> }
> doStuffWith(buffer[:n])
>
> ---
>
> Do any of the early Gophers remember the motivations for designing
> Read's semantics in that way? At the libc or syscall level (and my
> reading of FD.Read in internal/poll/fd_unix.go), I don't think
> read(fd, etc) can return both non-zero.
>
> Is it just that, if you've got a buffer of some sort (including the
> compress/* packages), it can be more efficient (1 Read call instead of
> 2) to return (positiveN, io.EOF)?
Some earlier discussions:
https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/jq8lAQhenaoJ
https://groups.google.com/g/golang-nuts/c/WGYJx3ICCW4/m/1L0WcN8eqmkJ
See in particular this message from Russ:
https://groups.google.com/g/golang-nuts/c/b78eRMOS0FA/m/sbbgr9MUo9QJ
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV1_rBwW2BcrV-1UkOFepvBq96bF7xfJRHp8tMiOsDpVQ%40mail.gmail.com.
Re: [go-nuts] Using new variable or updating existing variable in a loop
On Tue, Mar 19, 2024 at 9:36 AM Mohamad Rostami wrote:
>
> I've seen in many places in go source code re-declaring a variable with the
> same name.
> e.g:
> for i < j {
>h := ...
> }
> Instead of
> var h int
> for i < j {
>h = ...
> }
>
> So I did a benchmark to check the differences. I didn't find any performance
> related differences, but in terms of Stack Memory in use, the second approach
> is better than the first one.
>
> Not sure if the way is in standard library is by intention or something that
> should be ignored.
The two versions are basically equivalent. How are you measuring
stack memory usage? If they are different, there may be something to
fix in the compiler.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXLKoP6p5WpnaXkj-xbru2SRug_NCZxiMjjkYLV6ggeng%40mail.gmail.com.
Re: [go-nuts] debug/gosym.PCToLine breaks on cgo enabled binaries
On Wed, Mar 13, 2024 at 8:04 AM 'Grant Seltzer Richman' via golang-nuts wrote: > > I've been using the `Table.PCToLine` method to resolve program counters > (extracted via bpf) into functions with their file names and line numbers. > > It appears that this breaks when i'm testing it on a binary that has cgo > enabled. It does not fix it by compiling the binary statically. > > Another issue I have with this API is that creating the Table requires > passing the `.gosymtab` which of course is empty. Cgo binaries don't even > have it so I just pass an empty slice. > > Does anyone have alternatives to this package or possible explanations to why > these issues exist? When using cgo the final executable is generated by the C linker. If that process uses -fpie, as is the default on some systems, PCToLine may not work. Have you tried using runtime.FuncForPC? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVL1om9vxqe0d3SHKg8L0J-Djp5VSxA%2BB-fEjWaWQNN0A%40mail.gmail.com.
Re: [go-nuts] How To Reduce Json Marshalling Time
This thread has gotten heated. I think it's time to move on to different topics and give this discussion a rest. Thanks. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXbXBEMCpgPH_piQH0-jZoC_Lok94Oo9%2Bbe2fDBnaWgNA%40mail.gmail.com.
Re: [go-nuts] Why Go opt for using * in signature of function that returns a pointer instead of using &?
On Tue, Mar 5, 2024, 8:33 PM Matheus Fassis Corocher <
matheuscoroc...@gmail.com> wrote:
> I was studying about pointers and struct in Golang and one thing that I
> don't understand is why using * in return of signature of function instead
> of & if the return of function is an address of variable?
>
> The correct version that works:
>
> func NewVertex(X, Y int) **Vertex* {
> ...
> return {X, Y}
> }
>
> The version in my mind should be correct:
>
> func NewVertex(X, Y int) ** {
> ...
> return {X, Y}
> }
>
It was considered, but following the C programming language was the final
choice.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVeBEWYteh5p7-LCguL4e25vvycsBsta%2BLcm6tve1WWCg%40mail.gmail.com.
Re: [go-nuts] Enums, Go1 and proposals
On Mon, Mar 4, 2024 at 11:32 AM Mike Schinkel wrote:
>
...
> 4. Relax the allowable values that can be assigned to a `const` to include
> values that can be fully determined at compile time such as `const April =
> [1]byte{4}` thus allowing `const` and
> types of subtypes `struct`, `map`, array, and/or slices to be used as
> pseudo-enums.
...
> P.S. Seems to me that #4 might be the simplest way forward as it would allow
> for creation of types that cannot be represented as their literal subtype
> value to pass as a parameter to a `func`, and it would not require any new
> keywords or concepts added to Go the language, or at least I don't think it
> would?
>
> Is there any reason Go could not relax the allowable values for const to be
> able to support constructs that can be determined at runtime such as `const
> April = [1]byte{4}`?
I think this is https://go.dev/issue/6386.
There are subtleties. The simple version only works if the variable
can be declared and initialized in the same statement. That isn't
alway feasible, which is why init functions exist. It absolutely
prohibits circular data structures, which could be limiting. But
anything else requires some way to separate the declaration from the
initialization while still prohibiting the value from changing after
initialization.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV0YnFTzCGGANTOQ-ZTXb2gAiXUnXRbH1_P%3D1Qz4hH_AQ%40mail.gmail.com.
Re: [go-nuts] text template range over Rangefunc
On Mon, Mar 4, 2024 at 11:47 AM Ajay Kidave wrote:
>
> The https://go.dev/wiki/RangefuncExperiment change will be a great addition
> to the language. I wanted to know whether the text/html template std
> libraries will allow range over rangefunc. Currently, the doc for
> text/template says
>
> {{range pipeline}} T1 {{end}}
> The value of the pipeline must be an array, slice, map, or channel
>
> It would be great if rangefunc is supported in templates. The specific use
> case for me is passing a rangefunc created on a sql row iterator to a
> template.
Makes sense to me. Do you want to open a proposal at
https://go.dev/issue to add this to the template package? Thanks.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXv0podNt9Qyo4RpQxyR1OFx%3DWmPpnBPjJHSfSkAOtp9g%40mail.gmail.com.
Re: [go-nuts] Query Regarding ASAN C Call from Go Code
On Mon, Mar 4, 2024 at 9:55 AM Evgeny Chormonov wrote: > > I'm using Linux as my platform, but I'm curious why this solution is > restricted to Linux systems only? > https://github.com/golang/go/blob/master/src/runtime/asan/asan.go#L5 That's just the list of systems for which we support asan. Offhand I don't know what other systems the asan library supports. I don't think there is any obstacle to porting Go's asan support to other systems that the asan library supports, though of course some such ports would require new Go assembly code. Ian > понедельник, 4 марта 2024 г. в 00:43:09 UTC+3, Ian Lance Taylor: >> >> On Sun, Mar 3, 2024 at 1:25 PM Evgeny Chormonov wrote: >> > >> > I noticed that ASAN checker in the Go source code is defined using CGO >> > https://github.com/golang/go/blob/master/src/runtime/asan/asan.go >> > But the C ASAN functions are called from the Go runtime using assembly >> > code instead of a common CGO call. >> > https://github.com/golang/go/blob/master/src/runtime/asan_amd64.s#L36 >> > >> > This discovery has sparked my interest, and I am curious to know if I can >> > employ a similar method to execute my own C functions from my Go code. >> > Could you clarify if this is a viable option? >> >> Viable is in the eyes of the beholder. You can use a similar method. >> But you have to hand-write the assembler code for each C function you >> want to call. And if the C function ever blocks on, say, network I/O, >> your entire Go program can hang unexpectedly. We only use this >> technique for ASAN because we have a very limited number of functions >> to call, and we know for sure that those functions can never block. >> >> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/e5dd08b6-2e05-4bf2-9f51-89d2cb55622fn%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/CAOyqgcVEbVvz%2BTJYGtKbZe-3gETWWwC%2Bs1%3Dygahv9czC6xt_ug%40mail.gmail.com.
Re: [go-nuts] Enums, Go1 and proposals
On Mon, Mar 4, 2024 at 9:40 AM Jan Mercl <0xj...@gmail.com> wrote: > > The static type of an interface can be verified at compile time. The > value of a variable of an enum type (or a Pascal-like subrange) type, > cannot be verified at compile time in the general case. You would have > to add features Go does not have (like variable immutability) and/or > restrict some features for enum types that Go does have (like taking > address and using unsafe). Neither looks to me very probable, at least > in a short time. > > Those values can be however checked at runtime, similarly to > array/slice index bounds checking. For subrange-like enums it's rather > cheap and can be often eliminated. General, sparse-valued enums are > commonly too expensive to check at runtime for the compiler. to insert > them automatically. In order to use runtime checks reliably, then for something like an enum field in a struct where we have a pointer to the struct, we would have to validate the enum value each time it is used. And presumably panic if the value is out of range. This is doable but it's hard for me to believe that this is really what people want when they say that they want enums. In particular it's not how enums work in C/C++. It is arguably how enums work in Java and Python but since they don't have pointers the situation is somewhat different. Rust enums are significantly different in that each enum value can have its own individual attached data, making them more like tagged union types. I think the biggest reason that we haven't added enums to Go, beyond the predeclared constant iota, is that there is no consensus as to what people actually want. I'm not saying that if there was consensus that we would add enum types. But I do think it's very unlikely that we would add enum types in the absence of consensus. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVxUFges7bUGuK-nexBu%2BzmtZ%3DHeDMFTtDYe2pauHajxg%40mail.gmail.com.
Re: [go-nuts] Query Regarding ASAN C Call from Go Code
On Sun, Mar 3, 2024 at 1:25 PM Evgeny Chormonov wrote: > > I noticed that ASAN checker in the Go source code is defined using CGO > https://github.com/golang/go/blob/master/src/runtime/asan/asan.go > But the C ASAN functions are called from the Go runtime using assembly code > instead of a common CGO call. > https://github.com/golang/go/blob/master/src/runtime/asan_amd64.s#L36 > > This discovery has sparked my interest, and I am curious to know if I can > employ a similar method to execute my own C functions from my Go code. Could > you clarify if this is a viable option? Viable is in the eyes of the beholder. You can use a similar method. But you have to hand-write the assembler code for each C function you want to call. And if the C function ever blocks on, say, network I/O, your entire Go program can hang unexpectedly. We only use this technique for ASAN because we have a very limited number of functions to call, and we know for sure that those functions can never block. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVQ9zZaggpik5tu%3DvgYucUWXY57K601-a%3D6d4SXg_kidQ%40mail.gmail.com.
Re: [go-nuts] GO111MODULE=off go get deprecated?
On Sun, Mar 3, 2024 at 1:25 PM Jeffery Carr wrote: > > Has this been deprecated or maybe it is broken in debian sid, but: > > bash$ GO111MODULE=off go get -v go.wit.com/apps/test > go: modules disabled by GO111MODULE=off; see 'go help modules' > basj$ go version > go version go1.22.0 linux/amd64 > > this doesn't work anymore. Also, 'go help modules' is less than helpful. > > Is there some other way to download the actual sourcecode into > ~/go/src/mything/ anymore? > I think you may be seeing a bad error message. `go get go.wit.com/apps/test` doesn't work whether you are in module mode or not. With Go 1.21 I get > GO111MODULE=off ~/go1.21/bin/go get -v go.wit.com/apps/test package go.wit.com/apps/test: unrecognized import path "go.wit.com/apps/test": parse https://go.wit.com/apps/test?go-get=1: no go-import meta tags () I filed https://go.dev/issue/66080 for the odd difference in error messages. > This functionality was _PERFECT_ in my experience. I can't even imagine why > it would be deprecated. How in the world are you all developing complicated > software using GO without this working? Is this why everyone has gazillions > of internal/ packages and massive git repos? Most people simply use modules with no internal packages and with git repos that contain only their own code. That's kind of the point of modules, in fact. When I want to see the source code of an imported module, I build the package using `go build`, and then look in $GOPATH/pkg/mod. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU9OvSsdA8m6qXwcwuF8a-B4MxKVhaeHGPvVsM3ceAkvQ%40mail.gmail.com.
Re: [go-nuts] Plea for help diagnosing strange "signal: killed" issues in previously-working code
On Sat, Mar 2, 2024 at 9:59 AM Russtopia wrote: > > Symptom: mysterious "signal: killed" occurrences with processes spawned from > Go via exec.Cmd.Start()/Wait() The first step is to tell us the exact and complete error that you see. "signal: killed" can have different causes, and the rest of the information should help determine what is causing this one. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXR6hBSnGLjehwng%2BXp4QQ8ZznramEAZTmD%3D6tVwFirTg%40mail.gmail.com.
Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec
On Fri, Mar 1, 2024 at 6:17 PM Robert Engels wrote:
>
> The could be calling fork() as in the system call - which copies all file
> descriptors but I didn’t think Go processes could fork.
>
> Seems you would need to remap stdin and stdout in the fork to do anything
> useful.
>
> This sounds very PHP - what goes around comes around.
Good point, I am assuming that the OP is using the os/exec package to
start up a new copy of the process.
A simple fork without an exec can't work in Go, or in any
multi-threaded program.
Ian
> > On Mar 1, 2024, at 8:01 PM, Ian Lance Taylor wrote:
> >
> > On Fri, Mar 1, 2024 at 5:57 PM Jeff Stein wrote:
> >>
> >> I'm struggling to understand if I'm able to do something.
> >>
> >>
> >> In my very odd use case we are writing a websever that handles connections
> >> via a forked process.
> >>
> >> I have a listener process that listens for TCP connections.
> >>
> >> So each net.Conn that comes in we pull off its file descriptor:
> >>
> >> fd, err := conn.(*net.TCPConn).File()
> >>
> >> duplicate that file descriptor and then fork off a process passing in that
> >> file descriptor.
> >>
> >> In my forked handler I'll reconstruct the HTTP connection and "do stuff".
> >>
> >> The concern I'm having is that it appears when I fork a process I inherit
> >> all of the parent file descriptors so if I have say 5 incoming connections
> >> and then I fork my child process technically could write to a different
> >> connection.
> >>
> >> I've played around with the various options:
> >>
> >> cmd.SysProcAttr = {Setpgid: false,}
> >>
> >> and using cmd.ExtraFiles
> >>
> >> No matter what I do I seem unable to limit the sub process to ONLY using
> >> the specific File Descriptor I want it to have access to.
> >>
> >> I believe this is doable in C - but I'm not sure if I can do this in
> >> GoLang as-is without mods .
> >
> > What you are describing shouldn't happen. A child process should only
> > get the file descriptors explicitly passed via the os/exec.Cmd fields
> > Stdin, Stdout, Stderr, and ExtraFiles. So tell us more: OS and
> > version of Go, and what is showing you that all file descriptors are
> > being passed down to the child.
> >
> > 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.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUb27YBCyE52QisHLyB9XPPpEycMxt4FrFJogGsFMiemQ%40mail.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWYFJarW%3D%3DsGPC771-syZavevFTV9P1uzx59PL81eVFhw%40mail.gmail.com.
Re: [go-nuts] Limiting File Descriptors on Forked Linux cmd.exec
On Fri, Mar 1, 2024 at 5:57 PM Jeff Stein wrote:
>
> I'm struggling to understand if I'm able to do something.
>
>
> In my very odd use case we are writing a websever that handles connections
> via a forked process.
>
> I have a listener process that listens for TCP connections.
>
> So each net.Conn that comes in we pull off its file descriptor:
>
> fd, err := conn.(*net.TCPConn).File()
>
> duplicate that file descriptor and then fork off a process passing in that
> file descriptor.
>
> In my forked handler I'll reconstruct the HTTP connection and "do stuff".
>
> The concern I'm having is that it appears when I fork a process I inherit all
> of the parent file descriptors so if I have say 5 incoming connections and
> then I fork my child process technically could write to a different
> connection.
>
> I've played around with the various options:
>
> cmd.SysProcAttr = {Setpgid: false,}
>
> and using cmd.ExtraFiles
>
> No matter what I do I seem unable to limit the sub process to ONLY using the
> specific File Descriptor I want it to have access to.
>
> I believe this is doable in C - but I'm not sure if I can do this in GoLang
> as-is without mods .
What you are describing shouldn't happen. A child process should only
get the file descriptors explicitly passed via the os/exec.Cmd fields
Stdin, Stdout, Stderr, and ExtraFiles. So tell us more: OS and
version of Go, and what is showing you that all file descriptors are
being passed down to the child.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUb27YBCyE52QisHLyB9XPPpEycMxt4FrFJogGsFMiemQ%40mail.gmail.com.
Re: [go-nuts] Do we need to drain a closed channel ?
On Fri, Mar 1, 2024 at 6:26 AM Shubha Acharya wrote: > > I have been working with buffered channels. I have stumbled upon a scenario > where buffered channel will be closed and the receivers of the channel > terminates before consuming all the elements in the buffer. So my question is > will there be any issue regarding Garbage Collection of channel which > eventually leads to memory or resource leaks because of the left out items in > the buffer? or any other concerns that I must be aware of? No more than, say, a slice. An unreferenced channel will be garbage collected, which will remove references to any objects in the channel buffer. If those objects have no other references, they too will be garbage collected. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU6ogchtswNFtj%3Dsjry4pJZsioZBxANGZn3%2B2xz4XdFJg%40mail.gmail.com.
Re: [go-nuts] Re: How to have panic messages show in a PowerShell console
On Fri, Mar 1, 2024 at 5:09 AM jake...@gmail.com wrote: > > FWIW, in a very simple test on Windows 10 in a powershell console, running a > go executable built with go1.19 prints the panic just like in a regular cmd > console. There have been a lot of changes related to Windows consoles since the 1.6 release. Ian > On Wednesday, February 28, 2024 at 3:20:55 PM UTC-5 Thom BENTLEY wrote: >> >> Hi All, >> >> OS: Windows 10 >> GoLang: go1.6.3 windows/386 >> >> I am trying to have a go executable run and show the panics it causes in the >> PowerShell console. >> >> I think I can use GODEBUG, but all the examples I've seen so far are for >> Linux. >> I've set that variable to paniclog=1, but nothing changed. >> >> If I run go env, I don't see GODEBUG listed. >> Thanks in advance. >> >> >> >> The information in this email and any attachments are intended solely for >> the recipient(s) to whom it is addressed, and may be confidential and/or >> privileged. Any unauthorized distribution or copying of this transmittal or >> its attachments is prohibited. If you are not a named recipient or have >> received this email in error: (i) you should not read, disclose, or copy it, >> (ii) please notify the sender of your receipt by reply email and delete this >> email and all attachments. > > -- > 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/53c4fa69-32cd-4111-a0d5-d545d9851bf8n%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/CAOyqgcW4jB-iov82QjusrXZ6zZ2EjU3FHBjgqtTfB3uMP47Fxg%40mail.gmail.com.
Re: [go-nuts] go/version, "go2.00.1" < "go1.0.0"
On Mon, Feb 26, 2024 at 8:26 PM leo zeng wrote:
>
> package main
>
> import "go/version"
>
> func main() {
> var val int
> val = version.Compare("go2.00.1", "go1.0.0")
> print(val) // -1
> }
Please write plain text as plain text. It's difficult to read against
a dark background. Thanks.
The version code treats an unnecessary leading zero as an error. You
can try calling version.Lang: it will return the empty string for an
erroneous version.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXuYp6hLQNd7i-WUGsADhW64mxW_a408HhwmTmkD_SoHw%40mail.gmail.com.
Re: [go-nuts] Probable bug in database/sql
On Wed, Feb 21, 2024 at 4:27 PM Marco De Zio wrote: > > It seems to me that the second flag returned by Rows.nextLocked is wrongly > interpreted by Rows.Next as it sets rs.hitEOF = true when ok is false; also > Rows.nextLocked should set ok to true in some of the cases where right now > returns false. > > Reference in code: > https://github.com/golang/go/blob/507d1b22f4b58ac68841582d0c2c0ab6b20e5a98/src/database/sql/sql.go#L3027 > > Am I wrong ? The "ok" result of nextLocked is intended to report whether, when the method returns, the Rows is pointing at valid data. The "doClose" result reports whether the Rows should be closed. Given that understanding, the behavior of Next looks reasonable to me. As it happens when the current implementation returns "doClose" as true, it always returns "ok" as false. So the test "if doClose && !ok" is not strictly necessary; it could be replaced with "if doClose". But the current code doesn't seem wrong to me. Can you show a code sequence that seems buggy to you? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUUvSzDWim4dijEUcP5U2vx_xj_T-Y9SFczS4qMWuJFfQ%40mail.gmail.com.
Re: [go-nuts] Bad code contribution experience
On Mon, Jan 29, 2024 at 7:29 PM mr@gmail.com wrote: > > I want to vent my frustration. The experience of contributing has been > unpleasant for me. I have noticed that similar fixes are prioritized and > merged faster, while I spent time resolving the issue and reporting it, but > it did not receive an effective merge. Although it was during the freeze > period, I assumed it would be merged soon after the release. However, that > was not the case. In terms of submission time, my pull request was submitted > almost a month earlier than others', yet the newly submitted ones were merged > more quickly (https://go-review.googlesource.com/c/go/+/55). Perhaps I > should not have created a pull request during the freeze period. > > https://go-review.googlesource.com/c/go/+/543177 I'm sorry you had a bad experience. As you know, your earlier change was waiting for the release freeze. Then it looks like people simply didn't notice that the newer change more or less duplicated yours. We get so many changes that it's hard for anybody to keep track of them all. I understand your frustration. If you have any suggestions for how to avoid this kind of problem in the future, we would like to hear them. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX789ohvg2usXLJOigbKRGJ-6or9x7dkk6wcvFxgNFkLg%40mail.gmail.com.
Re: [go-nuts] Opening network connections blocks system thread
On Fri, Feb 9, 2024 at 11:57 AM Kurtis Rader wrote:
>
> The connect() syscall is normally blocking. It doesn't return until the
> connection is established or an error occurs. It can be made non-blocking by
> putting the file-descriptor into non-blocking mode before the connect() call.
> However, that then requires either an async callback or another syscall to
> check whether the connection was established or an error occurred. Neither
> approach is idiomatic Go.
That is true, but the Go standard library's net package does use
non-blocking calls to connect internally when implementing net.Dial
and friends.
I don't have any problem running the original program on Linux 6.5.13.
Ian
> On Fri, Feb 9, 2024 at 7:29 AM Venkat T V wrote:
>>
>> Hi,
>>
>> I am debugging an issue where a server opening a large number of connections
>> on startup sometimes dies with "program exceeds 1-thread limit". I know
>> file IO operations could lock up an OS thread. Still seeing this crash after
>> eliminating file IO, and it looks like "syscall.connect" is a blocking call
>> and could tie up an OS thread. This is on Linux with golang 1.21.7.
>>
>> I wrote a small program to test this out. Running this with "go run
>> osthreads.go -parallel 500 -threads 5" does trigger crashes sometimes, and I
>> see goroutines blocked on "syscall.connect" and "syscall.fcntl". Could I get
>> confirmation that this is expected behavior and Connect is a blocking
>> syscall?
>>
>> ===
>> package main
>>
>> import (
>> "flag"
>> "fmt"
>> "net"
>> "runtime"
>> "runtime/debug"
>> "sync"
>> "time"
>> )
>>
>> func main() {
>> numThreads := flag.Int("threads", 10, "number of threads (in addition to
>> GOMAXPROCS)")
>> parallelism := flag.Int("parallel", 100, "number of parallel goroutines to
>> start")
>> flag.Parse()
>>
>> maxThreads := runtime.GOMAXPROCS(-1) + *numThreads
>> fmt.Printf("GOMAXPROCS=%d, max threads=%d\n", runtime.GOMAXPROCS(-1),
>> maxThreads)
>> debug.SetMaxThreads(maxThreads)
>>
>> // Server that does not accept any connections
>> listener, err := net.Listen("tcp", "127.0.0.1:9090")
>> if err != nil {
>> fmt.Println(err)
>> return
>> }
>> defer listener.Close()
>>
>> wg := sync.WaitGroup{}
>> startSignal := make(chan struct{})
>>
>> // Spawn all goroutines
>> for i := 0; i < *parallelism; i++ {
>> wg.Add(1)
>> go func(id int) {
>> defer wg.Done()
>> <-startSignal
>>
>> conn, err := net.DialTimeout("tcp", "127.0.0.1:9090", time.Second)
>> if err != nil {
>> fmt.Printf("%d: error: %s\n", id, err)
>> return
>> }
>> defer conn.Close()
>> time.Sleep(time.Second)
>> }(i)
>> }
>>
>> time.Sleep(time.Second)
>>
>> // Start them all at once
>> close(startSignal)
>> wg.Wait()
>> }
>>
>> ===
>>
>> --
>> 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/33ab22bf-088a-4724-8cfb-62b7f51fca96n%40googlegroups.com.
>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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/CABx2%3DD92p6ZBjugETbX%3D5KjCqS7HH-Dv4PSuUg%3D9AZwBbioG1A%40mail.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVWPysC2vsqvXeVWmwswNBEQ5uaKQkPsZLguuiDnY_Omw%40mail.gmail.com.
Re: [go-nuts] Re: templates not working for me
On Wed, Feb 7, 2024 at 10:11 PM joseph.p...@gmail.com wrote: > > Variable substitution doesn't seem to work in an included template file. Is > that a known limitation? golang-nuts is for general discussion of Go, its tools, and its standard library. It's fine to ask about the Gin web framework here, but you are likely to get better answers if you ask in a forum that is focused on Gin. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU1rYb8F5_WLvN9tNk9tT4DpcMmtk8_7RbyBWK3_17Tjw%40mail.gmail.com.
Re: [go-nuts] Re: Do we need to call multipart.Part.Close
On Tue, Feb 6, 2024 at 6:29 AM Pedro Luis Guzmán Hernández wrote: > > Thanks Brian. That is an implementation detail though, so relying on it with > no mention in the documentation at all feels unsound. A Close method usually > means you have to defer it right after getting the resource, so I would have > expected the docs to be more clarifying on its usage. Yeah, the Close method doesn't seem to be documented at all. It would be nice if somebody sent a patch. Looks to me like you don't ever have to call Close, and that it should probably not have been exported. It is called by Reader.nextPart, and I don't immediately see any reason for it to be called anywhere else. Ian > El martes, 6 de febrero de 2024 a las 15:11:55 UTC+1, Brian Candler escribió: >> >> https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325 >> >> All it does is read all the remainder of the part to io.Discard. So if >> you're sure you've read each part before moving onto the next one, it looks >> like you should be good. >> >> On Tuesday 6 February 2024 at 13:34:16 UTC Pedro Luis Guzmán Hernández wrote: >>> >>> multipart.Part, returned by multipart.Reader's NextPart method, have a >>> Close() method. The only example here >>> https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() method >>> at all, so what's it purpose? Can we safely ignore it? >>> >>> The reason I'm asking is that, calling defer part.Closer is a bit annoying >>> when you loop through a Reader (see the example mentioned above). Calling >>> the defer within the loop means all parts are closed at the end of the >>> function. The alternative would be to have an anonymous function within the >>> loop and call defer within it, but it feels so awkward. > > -- > 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/6371b366-8474-46f0-99bc-510471fb879bn%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/CAOyqgcXp4_7wYsbgRWnuHJ1gto6V0YmpUXpKzBHC%2B%3D9W8A6u9w%40mail.gmail.com.
Re: [go-nuts] Embedding an interface with a function type
On Tue, Feb 6, 2024 at 6:43 AM Victor Manuel “Vitu” Giordano
wrote:
>
> I'm wondering why the language allow me to write something like this:
>
> type IncFunc func(a int) int
>
> type Incrementor interface {
> IncFunc // <-- THIS is allowed
> IncQuantity() int
> }
>
> (RTR example here)
>
> I don't get how I can make leverage of that.. or if has any sense at all 若
> As I recall an interface is a set of methods, and a method do have a name...
> the thing here is that the name if the name of the type not the function's
> name.
An interface type like that can be used as a constraint for a type
parameter. It can't be used as the type of a variable. As a type
parameter constraint it means that the type argument must be IncFunc.
It's fairly useless, but follows from the other rules about type
parameter constraints.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUS1V4ss%3D9tbAOxMBpCxNoFunJPgF_pgYFZw_%3DAB_%3DPOw%40mail.gmail.com.
Re: [go-nuts] Is this runtime.KeepAlive call really necessary
On Fri, Feb 2, 2024 at 10:05 AM Chong Yuan wrote:
>
> Here is the example in our gorocksdb:
>
> // Get returns the data associated with the key from the database.
>
> func (db *DB) Get(opts *ReadOptions, key []byte) (*Slice, error) {
>
>var (
>
> cErr*C.char
>
> cValLen C.size_t
>
> cKey= byteToChar(key)
>
>)
>
>cValue := C.rocksdb_get(db.c, opts.c, cKey,
> C.size_t(len(key)), , )
>
>runtime.KeepAlive(key) //<==this is the customization we
> added.
>
>if cErr != nil {
>
> defer C.rocksdb_free(unsafe.Pointer(cErr))
>
> return nil, errors.New(C.GoString(cErr))
>
>}
>
>return NewSlice(cValue, cValLen), nil
>
> }
>
> // byteToChar returns *C.char from byte slice.
>
> func byteToChar(b []byte) *C.char {
>
>var c *C.char
>
>if len(b) > 0 {
>
> c = (*C.char)(unsafe.Pointer([0]))
>
>}
>
>return c
>
> }
>
> My question is: if the keepalive(key) is necessary above. Will the "key" be
> GC-ed when calling into C.rocksdb_get(). Does the compiler know there’s a
> reference to “key” (using unsafe.pointer) and not collect “key” when running
> GC?
That call to runtime.KeepAlive does not look necessary. Pointers
passed to cgo functions are kept alive for the duration of the call.
The pointer returned by byteToChar will keep the slice's backing array
alive.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWv-JY_iA-TQW3Vvob-T9wmPxHW5fFPrreBJdvG-z%3D7YA%40mail.gmail.com.
Re: [go-nuts] Re: About allowing conversion from bool to int
On Fri, Oct 20, 2023 at 2:14 PM Victor Giordano wrote: > > My intention is to actually know any reason about not pushing forward that > proposal... because I need to understand why... *Is there any reason out > there? I don't know where to ask * > The first step is to read https://go.dev/issue/9367 and https://go.dev/issue/45320. There are various reasons in those issues. It's may be useful to distinguish _any reason_ from _a reason you agree with_. Even if you don't agree with the reasons in those issues, they are still reasons, and other people find them convincing. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXvu61ZzNt5d7RcUNTGM7NeoSkWOaNcWDygT0vArYrgKA%40mail.gmail.com.
Re: [go-nuts] What tool is used in Go Playground's import handling?
On Thu, Oct 19, 2023 at 8:31 PM Pratik Tamgole wrote:
>
> When I use packages, any packages in general, how does the import("fmt") line
> correct itself to include the used packages in the program? What tool is
> implemented here, I want to put the same in my editor.
https://pkg.go.dev/golang.org/x/tools/cmd/goimports
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXh9sCOB4K9tjiDEwRrU3dprwbZHsSwkFq0H8vPQFi56Q%40mail.gmail.com.
Re: [go-nuts] Can we not invoke methods on types referring to generics?
On Thu, Oct 19, 2023 at 6:18 PM Nurahmadie Nurahmadie
wrote:
>
> There are two ways to enable this, which are worth discussing further as of
> why Go decided to behave this way.
>
> To use type alias as mentioned before `type MatrixF64 = Matrix[float64]`,
> this is generally works but unfortunately, doesn't worth it in the case of
> aliasing primitives type, i.e. `type String = string` won't allow you to bind
> new methods to `String` unlike `type String string`. I would like to know why.
> To use type embedding such as: type MatrixF64 struct { Matrix[float64] },
> since struct/interface embedding will allow the parent struct to call
> embedded methods/fields directly.
>
>
> Again, I would love to see the motivation between these design decisions,
> pretty much I would like to allow new methods to be attached to type
> primitives without resorting to manual type casting / type assertion, but
> that's another topic.
Adding methods to a primitive type, or more generally adding methods
to a type defined in a different package, would cause different
packages to behave differently depending on whether they see the
methods. That would be confusing. It would meant that type
assertions would sometimes succeed and sometimes fail, depending on
the exact sequence of function calls 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUeKTpAzjOt3hyJpOfxbXQrB891c1BrG9zYKgaPOFU8xQ%40mail.gmail.com.
Re: [go-nuts] Can we not invoke methods on types referring to generics?
On Thu, Oct 19, 2023 at 5:14 PM Jason E. Aten wrote:
>
> Analogous to
>
> type IntSlice []int
>
> func (p IntSlice) Len() int { return len(p) }
> func (p IntSlice) Less(i, j int) bool { return p[i].val < p[j].val }
> func (p IntSlice) Swap(i, j int) { p[i], p[j] = p[j], p[i] }
>
> and then calling sort.Sort() on an IntSlice, I figured I
> could create a type that is a new name for an instantiated generic type and
> then call methods on that new type... but no?
>
> For example:
> https://go.dev/play/p/K5FGtNi6hLM
>
> package main
>
> import "fmt"
>
> type Addable interface {
> ~complex128 | ~complex64 | ~float64 | ~float32 |
> ~byte | ~uint16 | ~uint32 | ~uint64 |
> ~int8 | ~int16 | ~int32 | ~int64 | ~int
> }
>
> type Matrix[T Addable] struct {
> Nrow int
> Ncol int
> Dat []T
> }
>
> func (m *Matrix[T]) Col(j int) (res []T) {
> for i := 0; i < m.Nrow; i++ {
> res = append(res, m.At(i, j))
> }
> return
> }
>
> // At reads out the [i,j]-th element.
> func (m *Matrix[T]) At(i, j int) T {
> return m.Dat[i*m.Ncol+j]
> }
>
> func main() {
> m := [float64]{
> Nrow: 2,
> Ncol: 3,
> Dat: make([]float64, 2*3),
> }
> fmt.Printf("m.At(1,2) = '%v'", m.At(1, 2)) // this is fine, of course.
> }
>
> // I assumed this would work... but go 1.21 rejects the call to At() below.
> type MatrixF64 Matrix[float64]
>
> func UseMatrixF64(m *MatrixF64) {
>// so why won't this compile? if the same line in main() works?
> fmt.Printf("m.At(1,2) = '%v'", m.At(1, 2)) // compile error: m.At undefined
> (type *MatrixF64 has no field or method At)
> }
Using "type MatrixF64 ..." defines a new type that doesn't inherit any
of the method of the old type. That's how type definitions work in
Go. It will work as you expect if you use a type alias: "type
MatrixF64 = ...".
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUKo1n3BY5z1OWSFR4omZX4gFXpCgHg5%2BbHrb3jsk7E0w%40mail.gmail.com.
Re: [go-nuts] bufio.Scanner - possible bug or doc err?
On Thu, Oct 12, 2023 at 11:42 PM 'Mark' via golang-nuts wrote: > > Yes, I can see now. > > Perhaps consider changing: > > Programs that need more control over error handling or large tokens, or must > run sequential scans on a reader, should use bufio.Reader instead. > > to: > > Programs that need more control over error handling or large tokens (such as > lines longer than MaxScanTokenSize), or must run sequential scans on a > reader, should use bufio.Reader instead. Thanks, instead of that I added a link to Scanner.Buffer (https://go.dev/cl/535216). I hope that will help guide people in the right direction. Ian > On Thursday, October 12, 2023 at 8:56:05 PM UTC+1 Ian Lance Taylor wrote: >> >> On Thu, Oct 12, 2023 at 10:21 AM 'Mark' via golang-nuts >> wrote: >> > >> > The docs for bufio.Scanner do say >> > "Programs that need more control over error handling or large tokens, or >> > must run sequential scans on a reader, should use bufio.Reader instead" >> > Perhaps it would be more helpful to mention what the token length limit is? >> >> It's MaxScanTokenSize: https://pkg.go.dev/bufio#pkg-constants . See >> also https://pkg.go.dev/bufio#Scanner.Buffer . >> >> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/0392f8b3-a006-4bc0-aa54-3759aa0d3b7en%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/CAOyqgcUOUHbxEk%3DQM0yyVN68JMNDeFn_yJwi4B4RrA6s6SE1Qg%40mail.gmail.com.
Re: [go-nuts] bufio.Scanner - possible bug or doc err?
On Thu, Oct 12, 2023 at 10:21 AM 'Mark' via golang-nuts wrote: > > The docs for bufio.Scanner do say > "Programs that need more control over error handling or large tokens, or must > run sequential scans on a reader, should use bufio.Reader instead" > Perhaps it would be more helpful to mention what the token length limit is? It's MaxScanTokenSize: https://pkg.go.dev/bufio#pkg-constants . See also https://pkg.go.dev/bufio#Scanner.Buffer . 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXe6hk_R2KdQj19KNf9C5yc%2BWtpGXPO9u8tS7YjB9RCWA%40mail.gmail.com.
Re: [go-nuts] Question about runtime.Pinner
On Thu, Oct 12, 2023 at 5:06 AM Pascal Costanza wrote: > > I have a question about runtime.Pinner: The documentation states that you can > only pin an object when it’s the result of calling new, taking the address of > a composite literal, or taking the address of a local variable. > > At the same time, the Go language specification states that a slice created > with make allocates a hidden array, and gives the example that make([]int, > 50, 100) is the same as new([100]int)[0:50]. > > Taken together, this suggests that the following sequence should be correct: > > var p runtime.Pinner > s := make([]int, 100) > p.Pin([0]) > > …since [0] can be understood as being the result of calling new. > > Is that intended? Yes. > Also: I believe it would be good if the documentation would state that the > zero value for type runtime.Pinner is ready to use. That's the general default behavior for types in the standard library. If nothing says otherwise, the zero value is ready to use. That said, I'm not opposed to mentioning it if someone wants to send a patch. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXa4O0vzPD8XfTPpLaojL-xOC0Rs1PvspM5G0qzF-i1vQ%40mail.gmail.com.
Re: [go-nuts] The docs for secretbox seem very wrong
On Mon, Oct 9, 2023, 1:59 PM Dean Schulze wrote: > That is mixing concerns (low cohesion), though. At the very least they > need to explain that in the docs. Otherwise that first parameter makes no > sense. > This is a common design pattern in Go. We shouldn't expect that every function that uses it has to explain the idea. We should figure out a way for people to discover and understand it. Ian On Monday, October 9, 2023 at 2:51:11 PM UTC-6 David Anderson wrote: > >> The first parameter lets you avoid an allocation. If you're constructing >> a packet that consists of ciphertext surrounded by some framing, you can >> make([]byte, 0, lengthOfPacket) to preallocate the necessary amount of >> storage upfront. Then, calls to secretbox don't allocate. >> >> If you don't need that behavior, you can pass in a nil as the first >> parameter to get a fresh slice allocated for you by the append(), but in >> hot codepaths involving cryptography, being able to preallocate and reuse >> storage (e.g. via sync.Pool) can give you significant reduction in GC >> pressure. >> >> - Dave >> >> On Mon, Oct 9, 2023, at 08:43, Dean Schulze wrote: >> >> So why even bother with the first parameter then? That looks like a >> badly designed method signature. >> >> On Monday, October 9, 2023 at 8:12:33 AM UTC-6 Axel Wagner wrote: >> >> I get the impression that the thing you are missing is that appending to >> a slice does not modify it. That is, `append(s, x...)` modifies neither the >> length, nor the content of `s`, you have to type `x = append(s, x...)`. >> `Seal` (and `Open`) work exactly the same. They append to the `out` >> parameter - and to enable you to get at the slice, they return it. >> >> The docs could be slightly more clear, by explicitly stating that they >> return the appended-to slice.0 >> >> >> On Mon, Oct 9, 2023 at 3:46 PM Dean Schulze wrote: >> >> If the docs are correct, how do you append to nil? That's what the docs >> say. Take a look at them. >> >> Your code example shows the first parameter to Seal() can be nil. So >> what does that parameter do? How do you append to it? >> On Sunday, October 8, 2023 at 11:19:13 PM UTC-6 Axel Wagner wrote: >> >> For what it's worth, here is an example that demonstrates a typical >> encryption/decryption roundtrip, perhaps more clearly: >> https://go.dev/play/p/ZZry8IgTJQ_- >> The `out` parameter can be used to make this more efficient by using >> pre-allocated buffers (depending on use case) and there are cases where you >> don't have to send the nonce, because you can derive them from common data, >> which is why both of these parameters are there. But in the most common >> usage, you'd do what this example does. >> >> The example code from the docs tries to be a little bit more efficient >> and packs the `Box` struct into a single byte, perhaps at the cost of >> understandability. >> >> On Mon, Oct 9, 2023 at 7:06 AM Axel Wagner >> wrote: >> >> oh I forgot to emphasize: I don't believe the output is *really* >> ``. That is, I don't believe you can really treat >> the first N bytes as the encrypted text and decrypt it (say, if you didn't >> care about the authentication). It's just that you ultimately need to add >> 16 bytes of extra information to carry that authentication tag, which is >> why the box needs to be 16 bytes longer than the message. In reality, the >> two are probably cleverly mixed - I'm not a cryptographer. >> I just wanted to demonstrate where all the information ultimately goes. >> >> On Mon, Oct 9, 2023 at 7:03 AM Axel Wagner >> wrote: >> >> I don't really understand your issue. You call >> encrypted := secretbox.Seal(nonce[:], []byte(s), , ) >> That means you pass `nonce[:]` as the `out` argument, `s` as the >> `message` argument, and the nonce and key and assign the result to >> `encrypted`. >> According to the docs of `secretbox`, `Seal` will `append` the encrypted >> message to `nonce[:]` and that encrypted message will be 16 bytes longer >> than the message, which is 11 bytes long. Appending 37 (16+11) bytes to a >> 24 byte nonce gives you 51 bytes, which is what you observe as the length >> of `encrypted`. >> The length of `nonce` doesn't change (it's an array, after all) - but >> passing `append` to a slice does not change the length of the slice, it >> just returns a new slice, so that seems expected. >> >> So, from what I can tell, the code does exactly what the docs say it >> should do. >> >> > In their example code the out parameter is nil. So what does it do? >> >> Appending to `nil` allocates a new slice. The point of still accepting an >> `out` parameter is that you can potentially prevent an allocation by >> passing in a slice with 0 length and extra capacity (which can then be >> allocated on the stack, or which is from a `sync.Pool`). If you don't need >> that, passing in `nil` seems fine. >> >> > The second argument is encrypted[len(nonce):] which includes the >> Overhead at the start of the []byte. Apparently that
Re: [go-nuts] cgo.go: multiple definition of `c_test_func'
On Thu, Oct 5, 2023 at 3:13 PM sbezverk wrote:
>
> I struggle to understand why this simple cgo program does not get linked, I
> would provide example in playground, but it does not seem to support cgo.
>
> ```
> package main
>
>
>
> // #include
>
> //
>
> // extern int go_test_func(int c1, int c2);
>
> //
>
> // int c_test_func(int c1, int c2)
>
> // {
>
> // return go_test_func(c1,c2);
>
> // }
>
> import "C"
>
>
>
> import (
>
> "fmt"
>
> )
>
>
>
> //export go_test_func
Quoting from https://pkg.go.dev/cmd/cgo:
Using //export in a file places a restriction on the preamble: since
it is copied into two different C output files, it must not contain
any definitions, only declarations. If a file contains both
definitions and declarations, then the two output files will produce
duplicate symbols and the linker will fail. To avoid this, definitions
must be placed in preambles in other files, or in C source files.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUZBWMusm3vFbbATyYTOTyVt3CCgPvxTyC4kTb8g1iTjQ%40mail.gmail.com.
Re: [go-nuts] Inlining of runtime/internal/atomic.Cas
On Wed, Oct 4, 2023 at 5:36 AM Timur Celik wrote: > > Why is it that changes in the runtime package's atomic.Cas don't land in > my build? I suspect it has something to do with inlining of the > function, but even with `-gcflags=-l` the atomic.Cas original > implementation seems to get inlined. Functions that aren't inlined, > like atomic.Or have my changes incorporated. I tried deleting all > caches and rebuilt the compiler without success. It's because in general the compiler internally implements all the functions that appear in runtime/internal/atomic. The implementations in that package are not normally used at all, though they may be used when optimizations are disabled (-gcflags=-N). For the internal compiler implementations you can start by looking for OpAtomicCompareAndSwap32 in cmd/compile/internal/ssa. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWUGf1%2BJzvf%2BJxrpbxSWJOhv4-rydAZcbadzK3pmwEmUQ%40mail.gmail.com.
Re: [go-nuts] Generic "nillable" constraint
On Tue, Oct 3, 2023 at 5:57 PM Jon Watte wrote: > > > Can you give us an example? > > I already gave examples! They're in the thread! In reality, we have the > insides of a compiler where this would be helpful in more complex cases, and > we have the insides of a graphql and JSON web interface where this would be > helpful in a more complex case, but I'm not about to post the hundreds of > lines of code that would be needed to set those up. Thanks, but I'm looking for examples where it is important to permit only type arguments that can be compared to nil. Your examples seem to me to be cases that would be addressed if we had a standard way to compare a type to its zero value, such as https://go.dev/issue/61372 or https://go.dev/issue/62487 I'm asking whether there are cases where we want the former but not the latter. Thanks. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUyWo-NLfBd3fXkyW8za-DPpDiqBboZeyFtO23gg5po%2BQ%40mail.gmail.com.
Re: [go-nuts] Generic "nillable" constraint
On Tue, Oct 3, 2023 at 12:06 PM Jon Watte wrote:
>
> I don't want to include int or struct{} in this case. I care specifically
> about "can be compared to nil"
> The only thing I can do with a type parameter that is only constrained as
> "nil" is compare it to nil, or assign nil to it.
> This means approximately "any reference type" -- interfaces, pointers, maps,
> slices, chans...
It's not obvious that that is an interesting set of types. How often
do people want to write a generic function that permits any type that
can be compared to nil but does not permit any numeric or string type?
> But, let's put this out there:
> How would you, today, write a function that compacted a slice of interface,
> such that any "nil" interface value would be removed from the slice?
Unless I misunderstand, you seem to have shifted the goal a bit.
There is currently no way to restrict a type argument to be an
interface type, with or without your suggestion of a nil constraint.
> func Compact[T ?](sl []T) []T {
> j := 0
> for i := 0; i < len(sl); i++ {
> if el := sl[i]; el != nil {
> sl[j] = el
> j++
> }
> }
> return sl[:j]
> }
>
> There's nothing today I can put in place of the "?" to make this
> perfectly-reasonable generic function work.
> I propose I should be able to put "nil" in place of the "?" to make this
> work, and it would work for any reference type (that can be compared or
> assigned to nil.)
>
> Unless I'm missing something?
Well, here is a version that works for a slice of any type, including
an interface type. Arguably, though, using reflect is cheating.
func Compact[T any](s []T) []T {
j := 0
for _, v := range s {
vv := reflect.ValueOf(v)
if vv.IsValid() && !vv.IsZero() {
s[j] = v
j++
}
}
return s[:j]
}
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUaTdPE5-FGqqBRtr5kf-kM3b4rfsvwyFUBYu75gVZ8Ow%40mail.gmail.com.
Re: [go-nuts] Re: Is it expected that signal.NotifyContext() changes the execution thread?
On Sat, Sep 30, 2023 at 11:56 PM Kurtis Rader wrote: > > And having said that I just tested using runtime.LockOSThread() and it does > allow me to use the more obvious, natural, way to write the main() function. > Which still begs the question of why calling signal.NotifyContext() causes > subsequent code to run on a different OS thread. If nothing else this seems > like a side-effect that should be documented; along with the recommendation > of using runtime.LockOSThread() to avoid that side-effect. Goroutines are multiplexed onto operating system threads. A goroutine that does not call runtime.LockOSThread can move to a different operating system thread at (almost) any time. The goroutine scheduler can and does move goroutines between threads without regard to what those goroutines are doing. I don't know why this is happening particularly for signal.NotifyContext, but whatever the reason is, it's unlikely to be interesting. If your code cares about which operating system thread it runs on, it must use runtime.LockOSThread. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVdCDvnMk1a9OZKY9wokREmyVjGMpOiU5wUA19s%3D86eHA%40mail.gmail.com.
Re: [go-nuts] Generic "nillable" constraint
There is a lot more on this topic at https://go.dev/issue/61372. We're not sure how best to handle it. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVA%2BqNC8CshKonaSZ1zheZyEw6P%3D2pEYe4XqHyqmb4%3D%3Dg%40mail.gmail.com.
Re: [go-nuts] How to understand assembly code related to defer
On Tue, Sep 26, 2023 at 11:06 PM j2gg0s wrote:
>
> Related go code:
> 22 //go:noinline
> 23 func add(a, b int) int {
> 24 defer func() {
> 25 fmt.Println(3)
> 26 }()
> 27 return a + b
> 28 }
>
> Build by: GOOS=linux GOARCH=amd64 go21 build main.go
>
> Disassembler by: objdump -D -S main
> Assembly code:
> 179228 0047ae20 :
> 179229 ; func add(a, b int) int {
> 17923047ae20: 49 3b 66 10 cmpq16(%r14), %rsp
> 17923147ae24: 76 5b jbe 0x47ae81
>
> 17923247ae26: 55pushq %rbp
> 17923347ae27: 48 89 e5 movq%rsp, %rbp
> 17923447ae2a: 48 83 ec 18 subq$24, %rsp
> 17923547ae2e: 66 44 0f d6 7c 24 10 movq%xmm15, 16(%rsp)
> 17923647ae35: c6 44 24 07 00movb$0, 7(%rsp)
> 17923747ae3a: 48 c7 44 24 08 00 00 00 00movq$0, 8(%rsp)
> 179238 ; return a + b
> 17923947ae43: 48 01 d8 addq%rbx, %rax
> 179240 ; defer func() {
> 17924147ae46: 48 8d 0d 9b 06 02 00 leaq132763(%rip), %rcx
> # 0x49b4e8
> 17924247ae4d: 48 89 4c 24 10movq%rcx, 16(%rsp)
> 17924347ae52: c6 44 24 07 01movb$1, 7(%rsp)
> 179244 ; return a + b
> 17924547ae57: 48 89 44 24 08movq%rax, 8(%rsp)
> 17924647ae5c: c6 44 24 07 00movb$0, 7(%rsp)
> 17924747ae61: e8 7a 00 00 00callq 0x47aee0
>
> 17924847ae66: 48 8b 44 24 08movq8(%rsp), %rax
> 17924947ae6b: 48 83 c4 18 addq$24, %rsp
> 17925047ae6f: 5dpopq%rbp
> 17925147ae70: c3retq
>
>
> According to my understanding:
> 1. `17924147ae46: 48 8d 0d 9b 06 02 00 leaq132763(%rip),
> %rcx # 0x49b4e8 ` want to load address of
> main.add.func1 to register rcx. Is this understanding correct?
Sort of. 0x49b4e8 is the address of the function descriptor for
main.add.func1. If you look at address 0x49b4e8 you will see that it
contains the value 0x47aee0, which is the address of the code for
main.add.func1. For function descriptors see
https://go.dev/s/go11func.
> 2.1 rip 0x47ae4d, 0x47ae4d + 132763 = 0x49b4e8,
Yes, as the disassembler comment says.
> 2.2 main.add.func1's address is 0x47b0c0
> objdump -D -S main | grep "main.add.func1>:" -A 31
> 0047aee0 :
Well, 0x47aee0, not 0x47b0c0
> 2.3 i just found 0x49b4e8 in rodata
> 2.4 So, What is stored at 0x49b4e8?
The code for main.add.func1.
Ian
> 在2023年9月27日星期三 UTC+8 12:44:10 写道：
>>
>> On Tue, Sep 26, 2023 at 9:10 PM j2gg0s wrote:
>> >
>> > Already read it, I actually started here.
>> >
>> > What I can't understand is x64 rip-relative address.
>> >
>> > leaq 132795(%rip), %rcx # 0x49b4e8
>> >
>> > why 132795, and what is loaded into rcx
>>
>> It's a reference to another address in the program. The comment from
>> the disassembler tells you that it refers to the address go:func.* +
>> 0x220. The linker constructs the offset 132795.
>>
>> Ian
>>
>>
>>
>> > 在2023年9月27日星期三 UTC+8 09:38:17 写道：
>> >>
>> >> On Tue, Sep 26, 2023 at 7:43 AM j2gg0s wrote:
>> >> >
>> >> > How to understand assmbly code ` 47ae26: 48 8d 0d bb 06 02 00 leaq
>> >> > 132795(%rip), %rcx # 0x49b4e8 `
>> >>
>> >> The best place to start is
>> >>
>> >> https://go.googlesource.com/proposal/+/refs/heads/master/design/34481-opencoded-defers.md
>> >>
>> >> 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...@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/golang-nuts/69d8ca43-d4e7-4945-ab94-9951fa51188dn%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/3981c7b9-804b-4dd6-959c-9da0656bb317n%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/CAOyqgcXvLXWWDjFCctK2XqQQUTsBZELuZg0z7A0af-T775tP9A%40mail.gmail.com.
Re: [go-nuts] How to understand assembly code related to defer
On Tue, Sep 26, 2023 at 9:10 PM j2gg0s wrote: > > Already read it, I actually started here. > > What I can't understand is x64 rip-relative address. > > leaq132795(%rip), %rcx # 0x49b4e8 > > why 132795, and what is loaded into rcx It's a reference to another address in the program. The comment from the disassembler tells you that it refers to the address go:func.* + 0x220. The linker constructs the offset 132795. Ian > 在2023年9月27日星期三 UTC+8 09:38:17 写道： >> >> On Tue, Sep 26, 2023 at 7:43 AM j2gg0s wrote: >> > >> > How to understand assmbly code ` 47ae26: 48 8d 0d bb 06 02 00 leaq >> > 132795(%rip), %rcx # 0x49b4e8 ` >> >> The best place to start is >> >> https://go.googlesource.com/proposal/+/refs/heads/master/design/34481-opencoded-defers.md >> >> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/69d8ca43-d4e7-4945-ab94-9951fa51188dn%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/CAOyqgcXCEBHWBXsXEQJnrXZZOe5DRmLZKDsY2tZBE_J56dzjzw%40mail.gmail.com.
Re: [go-nuts] How to understand assembly code related to defer
On Tue, Sep 26, 2023 at 7:43 AM j2gg0s wrote: > > How to understand assmbly code ` 47ae26: 48 8d 0d bb 06 02 00 leaq > 132795(%rip), %rcx # 0x49b4e8 ` The best place to start is https://go.googlesource.com/proposal/+/refs/heads/master/design/34481-opencoded-defers.md 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUDJMURCNj22cTOc76b0GPe5MK4qBQSFUZo6xUBHFUXHA%40mail.gmail.com.
Re: [go-nuts] cgo and dynamic linking of shared labraries
On Tue, Sep 26, 2023 at 3:32 AM sbezverk wrote: > > Thank you for your reply, I was under impression that prototype definitions > come from C header files, and since the compilation phase completes with > success, cgo finds all necessary function definitions. My problem is at the > linking phase when the linker by some reason tries to resolve ALL functions > from the shared library, even those which are not directly used/called in CGO > code. I may have misunderstood the problem. Can you show more of the failing command? Ideally build with "go build -x" and show the failing command and the complete output. Thanks. > This causes CGO_LDFLAGS variable to be enormously long as I have to add > around 3k of libraries. Using LDFLAGS environment variable is no better, as > after adding all libraries to make LD happy, it exceeds the size limit and > pretty much kills bash. > > I am starting to get this: > > ``` > dev-1:/user/sbezverk/go_connect > ls > -bash: /bin/ls: Argument list too long > ``` > > For every internal bash command I try to execute. 3K in an environment variable doesn't sound like all that much. What operating system are you using? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUJS86q9S3yO7fOv-L-4GNrcR2cNqRoUyedytyuosoCig%40mail.gmail.com.
Re: [go-nuts] cgo and dynamic linking of shared labraries
On Sat, Sep 23, 2023 at 6:38 AM sbezverk wrote: > > Since I could not find the answer in the cgo documentation, I would really > appreciate if somebody could help me to understand why when I build cgo code > with calls to the shared library, the linker tries to find the shared library > even though it is instructed to build dynamic binary and not static. > > > > I have C built shared library, I have no control how it gets built, I only > have lib_blahblah_x64_86.so . There are 2 external functions > bind_wrapper/unbind_wrapper in that library which I call from cgo. > > > > Here is the command line I use to compile: > > > > CC=/bin/tools/llvm11/llvm-11.0-p25/bin/clang-11 go build -o go_connect > -linkshared -ldflags "-linkmode external -extldflags -dynamic" go_connect.go > > > > The compilation succeeds, but the linker is complaining: > > > > /tmp/go-link-2323626149/01.o: In function > `_cgo_df3b8c92b86e_Cfunc_bind_wrapper': > > /tmp/go-build/cgo-gcc-prolog:68: undefined reference to `bind_wrapper' > > /tmp/go-link-2323626149/01.o: In function > `_cgo_df3b8c92b86e_Cfunc_unbind_wrapper': > > /tmp/go-build/cgo-gcc-prolog:87: undefined reference to `unbind_wrapper' > > clang-11: error: linker command failed with exit code 1 (use -v to see > invocation) > > > > > > My expectation was that the linker will not check external references to > these functions while building the binary, and only when the binary is > executed, the dynamic linker will attempt to resolve them. I am suspecting I > got something wrong, appreciate if somebody could provide some suggestions. Usually people use #cgo LDFLAGS lines to tell cgo where to find the shared library you need to link against. You can also use the LDFLAGS environment variable to do this. The basic issue is that cgo needs to see the definition of the C function so that it knows what its arguments are, including their types. It needs the information in order to generate a call to the function. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUYh6rrqEzaN07MVaTxmxWeKOaqZOK8jUug4BifzzLyJg%40mail.gmail.com.
Re: [go-nuts] Golang+CGO using ucontext crash(on purpose) with SIGSEGV or SIGTRAP while using different stacks
On Sat, Sep 23, 2023 at 10:32 PM zk Z wrote: > > I'm currently writing a Golang + CGO program, and will use posix ucontext in > CGO. Since all my core logic will be in the bind function of ucontext, we > should catch up all the bad code. And I test it by accessing to the null > pointer, which give me totally different behaviors that all depending on the > stack location which ucontext used. Here are more details with simplified > example. > > If I allocate the ucontext stack on the thread's stack, it will trigger > SIGSEGV. But if I allocate it on the heap, it will first trigger SIGSEGV, and > then SIGTRAP while calling `morestack_noctxt` before calling into > `runtime.sigpanic`. How can I fix this or how can I just get SIGSEGV? Why it > need morestack? > > Here is my guess, but seems not correct: when I used the malloc stack, it was > treat as it has stack overflow, and should more stack, but end up find it's > g0, then fatal. But it seems the goroutine's stack is much more lower address > than thread's stack? This looks related to https://go.dev/issue/62130, which is partially fixed on tip. Perhaps you could try tip to see what happens? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX9TZF%3DK4DumSXER4uzTnJOr739f9y58Zn10s8YaTLtNA%40mail.gmail.com.
Re: [go-nuts] panic: nil dereference in autogenerated hash function
On Fri, Sep 22, 2023 at 9:15 AM Shivaram Lingamneni wrote: > > I'm having difficulty understanding how this code could produce a nil > dereference, unless some runtime assumptions are being violated (maybe the > string pointer and length are out of sync due to a data race)? I agree: this looks like some form of memory corruption. Run the code under the race detector. Look closely at any uses of cgo or the unsafe package. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW29rf5C2ieFN58A0C8o7f9WBTXLPc6Fxd7o_Z7s9XTbQ%40mail.gmail.com.
Re: [go-nuts] NTFS deduplicated files changed from regular to symlink in go 1.21
[ + Quin Muntal ] On Thu, Sep 21, 2023 at 10:34 AM Simon Frei wrote: > > Hi, > > We got a report in syncthing that some files fail to sync on an ntfs > filesystem with deduplication enabled after upgrading the app: > https://github.com/syncthing/syncthing/issues/9120 > The only change relevant to filesystem handling there was going from go1.20 > to go1.21. Debug logging shows that `IsRegular` returns false on `LStat` > result of this file, while this is a regular (though possibly deduplicated) > file so should be true and was true before. > > This change in go 1.21 seems like it's related, as it deals with reparse > points: > https://github.com/golang/go/commit/3e44b7d07a7b3c6233eb1bf4cf3cb00a0b85adec > And so does ntfs deduplication according to this doc: > https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/understand > > Now my question is if this was an intentional change, or if this is a > regression and should be filed as a bug. The commit message suggest it might > more likely be a regression, as it seems focused on performance and mentions > symlinks being rare, so I doubt ntfs deduplication was on the radar. > > Any comments about this, specifically if you feel like this might be a > regression/should be filed as a bug. I haven't tried to repro, don't have a > windows ntfs setup handy, but the issue seems clear enough to start reason > about it. > > Cheers, > Simon > > -- > 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/c7b9a889-b659-4022-a5f1-439bde7e7b8fn%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/CAOyqgcVciWdNmkizj8bvv5MF4mib9fg%3DUOTeysMjQ18uAxYUNA%40mail.gmail.com.
Re: [go-nuts] Go 1.21.0 panics on macos ventura 13.5.2
On Thu, Sep 21, 2023 at 2:16 PM Pierre Laplante wrote: > > Running make planic with: > > fatal error: forcegc: phase error Note for mailing list: this was reported as https://go.dev/issue/63151. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU8T%2BqRMPRGDhRn5h8Tkyi_O%3DV33cRS3s%2BynJMmRW3j-A%40mail.gmail.com.
Re: [go-nuts] semantics of panic stack traces
On Sun, Sep 17, 2023 at 2:44 PM 'Dan Kortschak' via golang-nuts
wrote:
>
> I'm trying to get my head around a panic stack trace from a user
> report[1].
>
> The parameter value make very little sense to me based on what they
> should be from following the program logic. For example the {0x0?, 0x0,
> 0x1?} (a slice header len=0) in
>
> github.com/elastic/beats/v7/winlogbeat/sys/wineventlog.evtFormatMessage(0xc0003f62d0?,
> 0x23?, 0x0?, {0x0?, 0x0, 0x1?}, 0x1?)
>
> github.com/elastic/beats/v7/winlogbeat/sys/wineventlog/format_message.go:81
> +0xa5 fp=0xc00034ae88 sp=0xc00034ad98 pc=0x176f645
>
> means that (from program logic) the 4th (length) and 5th (pointer)
> parameters in
>
> github.com/elastic/beats/v7/winlogbeat/sys/wineventlog._EvtFormatMessage(0x23?,
> 0x3600700?, 0x0, 0x0, 0xc000d5e978?, 0x1, 0x0, 0x0?, 0x0?)
>
> github.com/elastic/beats/v7/winlogbeat/sys/wineventlog/zsyscall_windows.go:132
> +0xf2 fp=0xc00034ad98 sp=0xc00034acf0 pc=0x177f152
>
> should be 0 and 0 AFAICS. But this is not the case; the 5th is
> 0xc000d5e978?.
>
> What am I failing to understand here?
First I have to say that that code is not safe. It violates the
unsafe.Pointer rules. The Windows function EvtFormatMessage takes a
pointer. The Go function evtFormatMessage converts the slice address
to uintptr, and passes that. The conversion to uintptr is permitted
in the call to EvtFormatMessage, but that is not where it takes place.
So this code is wrong, although in practice it will usually work as
expected.
That aside, I don't think you're misunderstanding anything. The ? in
the stack traceback means that the value might be wrong. That ? is
printed when the value is not live, meaning that the compiler may have
overwritten or discarded the value at the point of the stack
traceback. In this case the "values" slice is dead at the point of
the call to _EvtFormatMessage. Likely the values shown in the call to
evtFormatMessage are simply wrong.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVGJci0mtAf_Rt5zzOZVNug%2BHPyOUvK_i9hyShQDGHLjw%40mail.gmail.com.
Re: [go-nuts] How ignore a subdirectory
On Wed, Sep 13, 2023 at 12:27 PM 'John Souvestre' via golang-nuts wrote: > > What is TIL? https://knowyourmeme.com/memes/today-i-learned-til 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVviOBQf70XH6LonsQhma79HFKMpiQ-RO%3DAZfwD4JC%2Bkg%40mail.gmail.com.
Re: [go-nuts] How ignore a subdirectory
On Tue, Sep 12, 2023 at 8:47 PM 'John Souvestre' via golang-nuts wrote: > > I’m trying to run gofmt on all of the .go files in a directory, but not any > subdirectories. I have tried using “.” for the target. It does get all of > the .go in the current directory, but it also does all the .go files in > subdirectories. To be more specific: There is one particular subdirectory > which I don’t want it to process: “_Save”. > > > > The https://pkg.go.dev/cmd/go documentation says: > > > > Directory and file names that begin with "." or "_" are ignored by the go > tool, as are directories named "testdata". Note that this applies to "go fmt", not "gofmt". 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV46-W-4W1WrzeC0VzfU2YAtjV8XCLOu8iqx9rQ9W%3DgbQ%40mail.gmail.com.
Re: [go-nuts] x/mobile: avoid to catch sigabort signal
On Thu, Sep 7, 2023 at 11:41 PM Danilo bestbug wrote: > > Some weeks ago I've opened a possible bug on github and the only response I > received is a reference to > "This looks like the program (the Go runtime, or not) intentionally crashing > when it is already in a bad condition, like receiving an unhandled signal on > a non-Go thread." > > I would like to stop the GO system to do this kind of behaviour (intercepting > unhandled signal) otherwise the team who work on the crash keep searching the > problem on the GO thread crashed instead of elsewhere. This for us is a big > problem and I love if someone can help me to address this matter! I'm sorry, I don't really understand what you are asking. What I can tell you is that signal handling in Go programs is managed via the os/signal package. See https://pkg.go.dev/os/signal. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXYe-n%3DZvF4h5sMJWZO%2BGTYVfMJgvwS-KUPi1yogDyk3g%40mail.gmail.com.
Re: [go-nuts] Is it safe to keep noCopy types in a slice which might copy on re-alloc?
On Sun, Aug 27, 2023 at 2:28 PM Antonio Caceres Cabrera
wrote:
>
> Thanks for your reply, Ian.
> I've decided on using a []*Foo now. Just to clarify, however: In general,
> copying/assigning from a struct literal as in
> a[i] = Foo{}, is that always safe for these sync types? Or generally, is
> copying their "untouched" zero-values always safe?
Yes, in general it's safe to copy the untouched zero value of these types.
Ian
> On Sunday, August 27, 2023 at 7:05:15 PM UTC+2 Ian Lance Taylor wrote:
>>
>> On Sun, Aug 27, 2023 at 7:54 AM Antonio Caceres Cabrera
>> wrote:
>> >
>> > Go vet complains about this minimal example code
>> >
>> > type Foo struct {
>> > val atomic.Uint64
>> > }
>> >
>> > func main() {
>> > var foos = make([]Foo, 0)
>> > var bar Foo
>> > bar.val.Store(5)
>> > foos = append(foos, bar) // call of append copies lock value:
>> > example.com/foo.Foo contains sync/atomic.Uint64 contains sync/atomic.noCopy
>> >
>> > }
>> >
>> > Because the types of the sync package are not supposed to be copied.
>> > This is also true for sync.Map, sync.Mutex, sync.WaitGroup etc.
>> >
>> > However, if I instead copy in a zero-value Foo and then set that, go vet
>> > does not complain, even if later appends are done:
>> >
>> > func main() {
>> > var foos = make([]Foo, 0)
>> > foos = append(foos, Foo{})
>> > foos[0].val.Store(5)
>> > foos = append(foos, Foo{})
>> > foos = append(foos, Foo{})
>> > // append some more
>> > // ...
>> > fmt.Println(foos)
>> > }
>> >
>> > However, is this supposed to be safe, or is go vet just not catching it?
>> > Even if copying a zero-value of such a type is safe, append() might have
>> > to re-allocate the underlying array, which includes copying the existing
>> > values, which might already have been used, as foo[0] has been in this
>> > case. This would violate the noCopy trait of the type. My question is thus:
>> >
>> > Is it safe to keep nocopy types from the sync and sync.atomic packages in
>> > a slice, given that they might internally be copied when the slice is
>> > appended to?
>> >
>> > Of course, copying these types is not by itself atomic or synchronized
>> > with other accesses. So let's assume that I, as the programmer, guarantee
>> > that while an append happens, this slice will only be accessed by the one
>> > appending goroutine, using other synchronization primitives, such as
>> > mutex, channels etc. or by only running these appends in the main before
>> > any other go-routine is started.
>>
>> Doing an append on a slice of types that contain atomic types is in
>> general not safe and go vet is not catching it.
>>
>> If your program can guarantee that while the append is happening there
>> is no concurrent access to the atomic types, then I think that is
>> safe. It's not safe in general for all nocopy types, but it's safe
>> for types like atomic.Uint64. It doesn't seem like a very clear way
>> to write a program though. It may be better to use a slice of
>> pointers: in your example, []*Foo. Or precount the size of the slice
>> to ensure that append won't copy it.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6ad297ba-19d4-4eaf-a2c2-252ca9db390cn%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/CAOyqgcUY9R%2Bm74Dzf4Z_Gp1BQ8eCRBNzrNW4xW1PEbQPfgK7pg%40mail.gmail.com.
Re: [go-nuts] Is it safe to keep noCopy types in a slice which might copy on re-alloc?
On Sun, Aug 27, 2023 at 7:54 AM Antonio Caceres Cabrera
wrote:
>
> Go vet complains about this minimal example code
>
> type Foo struct {
> val atomic.Uint64
> }
>
> func main() {
> var foos = make([]Foo, 0)
> var bar Foo
> bar.val.Store(5)
> foos = append(foos, bar) // call of append copies lock value:
> example.com/foo.Foo contains sync/atomic.Uint64 contains sync/atomic.noCopy
>
> }
>
> Because the types of the sync package are not supposed to be copied.
> This is also true for sync.Map, sync.Mutex, sync.WaitGroup etc.
>
> However, if I instead copy in a zero-value Foo and then set that, go vet does
> not complain, even if later appends are done:
>
> func main() {
> var foos = make([]Foo, 0)
> foos = append(foos, Foo{})
> foos[0].val.Store(5)
> foos = append(foos, Foo{})
> foos = append(foos, Foo{})
> // append some more
> // ...
> fmt.Println(foos)
> }
>
> However, is this supposed to be safe, or is go vet just not catching it?
> Even if copying a zero-value of such a type is safe, append() might have to
> re-allocate the underlying array, which includes copying the existing values,
> which might already have been used, as foo[0] has been in this case. This
> would violate the noCopy trait of the type. My question is thus:
>
> Is it safe to keep nocopy types from the sync and sync.atomic packages in a
> slice, given that they might internally be copied when the slice is appended
> to?
>
> Of course, copying these types is not by itself atomic or synchronized with
> other accesses. So let's assume that I, as the programmer, guarantee that
> while an append happens, this slice will only be accessed by the one
> appending goroutine, using other synchronization primitives, such as mutex,
> channels etc. or by only running these appends in the main before any other
> go-routine is started.
Doing an append on a slice of types that contain atomic types is in
general not safe and go vet is not catching it.
If your program can guarantee that while the append is happening there
is no concurrent access to the atomic types, then I think that is
safe. It's not safe in general for all nocopy types, but it's safe
for types like atomic.Uint64. It doesn't seem like a very clear way
to write a program though. It may be better to use a slice of
pointers: in your example, []*Foo. Or precount the size of the slice
to ensure that append won't copy it.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVFiJamWtHbuF_wDLtq51uQmqWM6tL6m6eQ%3DSNwmjGPkQ%40mail.gmail.com.
Re: [go-nuts] Reason for "goto jumps over declaration" being disallowed
On Sat, Aug 26, 2023 at 2:11 PM Mike Schinkel wrote:
>
> Question about disallowing `goto ` jumping over a variable declaration?
>
>
> And please, before bikeshedding opinions about the use of `goto` pro or con —
> note that the Go standard library uses `goto` in some places — this question
> is purely for me to gain better understanding the choices made with the Go
> compiler.
>
>
> Question. Was it:
>
>
> 1. Somehow logically required by the compiler, and if so can you elaborate
> why?
>
> 2. A design decision made, and if so what what the rationale for the design
> decision?
>
> 3. A limitation place on GoLang for some other reason, and if so, what and
> why?
>
>
> I have prepared an example showing use of `goto` that compiles and one that
> does not at this playground URL:
>
>
> https://goplay.tools/snippet/tSAbWhmiCZK
>
>
> Hoping to hear from someone who actually knows why the decision was made as
> opposed to someone who might just be guessing at the reason.
Consider a function like
func F() {
goto lab
x := 1
lab:
fmt.Println(x)
}
This function is forbidden today. If it were permitted, what should it print?
If the answer to that question seems obvious, what about a case like
func F() {
goto lab
x := func() int {
fmt.Println("setting x")
return 1
}()
lab:
fmt.Println(x)
}
Should that print "setting x"?
Rather than attempt to answer these kinds of questions, Go simply
forbids cases like this.
Note that Go is not the only language with this restriction. This
similar C++ function is invalid, because the goto crosses the
initialization of the variable.
int f() {
goto lab;
int x = 1;
lab:
std::cout << x;
return 0;
}
If you are interested in this topic you may be interested in
https://go.dev/issue/27165 and https://go.dev/issue/26058.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVuD0-3r37FfFHdBgoTFX7-1QVUY54MYgG0XKjvQVeKnQ%40mail.gmail.com.
Re: [go-nuts] Would it be possible to make this work in the future?
On Fri, Aug 25, 2023 at 1:55 PM محمد بومنذر
wrote:
>
> It's actually plain text but copied right from my editor with the theme
> styles, I'll use the playground for future examples.
Thanks. Then I guess my request is to paste as plain text without styles.
Ian
> Thank you for clarifying. I do see how the compiled version will need to be
> repetitive, although as you mentioned this piece of code is not a common case.
> في Friday, August 25, 2023 في تمام الساعة 11:43:05 PM UTC+3، كتب Ian Lance
> Taylor رسالة نصها:
>>
>> On Fri, Aug 25, 2023 at 7:43 AM محمد بومنذر
>> wrote:
>> >
>> > I'm writing a parser based on Go's `encoding/xml`, I tried to use the
>> > following pattern but it was deemed invalid:
>> >
>> > ```
>> > To me, it'd make sense if it was allowed since both types are structs and
>> > both of them share the field `Name` with the subsequent field `Local`.
>>
>>
>> Please post code as plain text or as a link to the Go playground, not
>> as an image. Images are much harder to read, and there is no reason
>> to use them for plain code. Thanks.
>>
>> We are unlikely to implement such a language feature. We would have
>> to have careful definitions of what kinds of code are permitted in a
>> case with multiple types. And since in general there is no reason to
>> expect that the fields are at the same location, we would have to
>> compile the case differently for each type anyhow. And the code might
>> actually behave quite differently; should we permit code like
>>
>> switch x := v.(type) {
>> case []int, map[int]int:
>> return x[1]
>> }
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/312da70b-11c3-43b1-b53e-6d1a8e622becn%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/CAOyqgcUzp9p4dhzN%3DD-p2HsSvN%3DgsmiFX65RRdXqUhj5wJ8VRQ%40mail.gmail.com.
Re: [go-nuts] Would it be possible to make this work in the future?
On Fri, Aug 25, 2023 at 7:43 AM محمد بومنذر
wrote:
>
> I'm writing a parser based on Go's `encoding/xml`, I tried to use the
> following pattern but it was deemed invalid:
>
> ```
> To me, it'd make sense if it was allowed since both types are structs and
> both of them share the field `Name` with the subsequent field `Local`.
Please post code as plain text or as a link to the Go playground, not
as an image. Images are much harder to read, and there is no reason
to use them for plain code. Thanks.
We are unlikely to implement such a language feature. We would have
to have careful definitions of what kinds of code are permitted in a
case with multiple types. And since in general there is no reason to
expect that the fields are at the same location, we would have to
compile the case differently for each type anyhow. And the code might
actually behave quite differently; should we permit code like
switch x := v.(type) {
case []int, map[int]int:
return x[1]
}
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWKCshzVkTTy2hY0YQLk6fU5rdeB%2B_kTbNEhdE_P32%3DHQ%40mail.gmail.com.
Re: [go-nuts] Replicating C unions with unsafe, arrays, and some constant arithmetic
Note that is not permitted by the rules of the unsafe package, and that in
particular it will break the garbage collector if any of the types stored
in the union contain pointer fields.
Ian
On Thu, Aug 24, 2023, 7:59 PM aind...@gmail.com wrote:
> I found this trick recently to replicate a C union in Go with
> unsafe.Sizeof, arrays, and some constant arithmetic. This lets you
> stack-allocate data that needs to be the max size of multiple other data
> types. So given a type A and B that you want to union, you can say
>
> const ASize = int64(unsafe.Sizeof(*new(A)))
> const BSize = int64(unsafe.Sizeof(*new(B)))
> const diff = ASize - BSize
> const max = ASize - ((diff>>(bits.UintSize-1))&1)*diff
>
> var storage [max]byte
> *(*A)(unsafe.Pointer())
> *(*B)(unsafe.Pointer())
>
> This process can be repeated for any number of types. For example, if you
> wanted to represent a tagged union defined like
>
> type A =
> | B
> | C int
> | D (a: int, b: int)
>
> you could lower it to something like
>
> const size = int64(unsafe.Sizeof(*new(B)))
> const size0 = int64(unsafe.Sizeof(*new(C)))
> const diff = size - size0
> const max = size - diff*((diff>>(bits.UintSize-1))&1)
> const size1 = int64(unsafe.Sizeof(*new(D)))
> const diff0 = size1 - max
> const max0 = size1 - diff0*((diff0>>(bits.UintSize-1))&1)
>
> type A struct {
> tag uint8
> storage [max0]byte
> }
> type B struct{}
> type C int
> type D struct {
> a int
> b int
> }
>
> Unfortunately, the resulting code is pretty inefficient compared to
> interfaces or struct embedding. It might be that the use of unsafe is
> hindering compiler optimizations, or maybe it's an alignment issue.
>
> --
> 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/5d150c6a-3ecb-4cb8-91b3-c048940294aen%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/CAOyqgcXKkbH8atMfigwu0kjk-5mMcj_cPt8Y%3Dn%3DvoOZuzAmHWA%40mail.gmail.com.
Re: [go-nuts] Crash using gccheckmark=1, possible GC bug?
On Fri, Aug 18, 2023 at 8:12 AM Tibor Halter wrote:
>
> Hi Elias, thanks for chiming in!
>
> > The Go garbage collector is precise in that it only considers pointers when
> > determining memory that can be freed.
>
> Agreed, but it is not as precise on _what_ is a pointer. Specifically, which
> matters?
> - the type used upon allocating the memory, or
> - the type used upon writing to it.
>
> Because *T or unsafe.Pointer is required upon writing to a memory location
> for it to be marked as a pointer, I came to the conclusion that the type upon
> writing is what matters.
>
> So then both types need to be pointers?
>
> Does that mean there is no way to define a struct-like memory layout
> dynamically, that contains a mix of pointer and non-pointer types, in a way
> that is supported by the GC?
> (This is what I'm trying to do.)
The rule is pretty simple: a pointer must always have a pointer type.
That includes when it is in a variable and when it is stored in
memory. In your terms, what matters is the type used upon allocating
the memory.
Your code is not following any of the patterns permitted for
unsafe.Pointer (any patterns that are not explicitly permitted are
forbidden). The code is effectively converting from *byte to *Num.
As it says at https://pkg.go.dev/unsafe#Pointer that kind of
conversion is only permitted if the types in question "share an
equivalent memory layout". byte and Num have different memory
layouts.
You can define a struct-like memory layout dynamically by using
reflect.StructOf.
Ian
> On Friday, August 18, 2023 at 3:49:03 PM UTC+2 ma...@eliasnaur.com wrote:
>>
>> On Friday, 18 August 2023 at 05:57:38 UTC-6 Tibor Halter wrote:
>>
>> Thanks Ian!
>>
>> I have managed to strip it down to its essence, see code below.
>>
>> Summary of what I'm doing
>> - reserve memory with make([]byte)
>> - get pointer to underlying array
>> - cast it to type Num
>> - write pointer #2 into it
>> - force GC()
>> - GC does not follow pointer #2, memory is freed
>>
>>
>> The Go garbage collector is precise in that it only considers pointers when
>> determining memory that can be freed. In your scenario and demonstration
>> program you explicitly store a pointer in a byte slice, effectively making
>> it invisible to the collector.
>>
>>
>> --
>>
>>
>> package debug
>>
>> import (
>> "testing"
>> "runtime"
>> "unsafe"
>> )
>>
>> type Num struct {
>> numData *uint64
>> }
>>
>> func Test(t *testing.T) {
>> n := uint64(123456789)
>> numMemSize := 8
>> b := make([]byte, numMemSize, numMemSize)
>> sliceDataPtr := unsafe.Pointer(unsafe.SliceData(b))
>> (*Num)(sliceDataPtr).numData =
>>
>>
>> The pointer to stored in b here is effectively hidden from the collector.
>>
>>
>>
>> runtime.GC()
>>
>>
>> With no more visible references to (the supposedly heap-allocated) n, it can
>> be freed.
>>
>>
>>
>> act := (*Num)(sliceDataPtr).numData
>> if *act != 123456789 {
>> t.Fatalf("v[%X]", *act)
>> }
>> }
>>
>>
>> Elias
>
> --
> 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/5051da1c-36de-4699-906c-ff8f50754404n%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/CAOyqgcXKkZdzVebd3U%3DBQ25scsyZC5g%2BKWNS2DFgFhmgHQkb-g%40mail.gmail.com.
Re: [go-nuts] Crash using gccheckmark=1, possible GC bug?
On Thu, Aug 17, 2023 at 5:41 PM Tibor Halter wrote:
>
> I get this crash when using the GODEBUG option gccheckmark=1:
>
> runtime: marking free object 0xc0016c5668 found at *(0xc0046ca8e0+0x8)
> base=0xc0046ca8e0 s.base()=0xc0046ca000 s.limit=0xc0046cc000 s.spanclass=8
> s.elemsize=32 s.state=mSpanInUse
> *(base+0) = 0x15e11f0
> *(base+8) = 0xc0016c5668 <==
> *(base+16) = 0x28
> *(base+24) = 0xc004642030
> obj=0xc0016c5668 s.base()=0xc0016c4000 s.limit=0xc0016c5ff8 s.spanclass=6
> s.elemsize=24 s.state=mSpanInUse
> *(obj+0) = 0x15e0e80
> *(obj+8) = 0xc00039c080
> *(obj+16) = 0xc0016c5650
> fatal error: marking free object
>
> runtime stack:
> runtime.throw({0x132362a?, 0x3?})
> /usr/local/go-1.21.0/src/runtime/panic.go:1077 +0x5c fp=0x7f9636366d48
> sp=0x7f9636366d18 pc=0x43aa9c
> runtime.greyobject(0xc0016c5668, 0x1?, 0x7f9636366df8?, 0x6590?,
> 0x7f9636366df8?, 0x7f9636366de0?)
> /usr/local/go-1.21.0/src/runtime/mgcmark.go:1476 +0x285 fp=0x7f9636366d98
> sp=0x7f9636366d48 pc=0x424d85
> runtime.scanobject(0xc0046ca8e0, 0xc4d240)
> /usr/local/go-1.21.0/src/runtime/mgcmark.go:1336 +0x171 fp=0x7f9636366e20
> sp=0x7f9636366d98 pc=0x424711
> runtime.gcDrain(0xc4d240, 0x7)
> /usr/local/go-1.21.0/src/runtime/mgcmark.go:1103 +0x1ba fp=0x7f9636366e80
> sp=0x7f9636366e20 pc=0x423fba
> runtime.gcBgMarkWorker.func2()
> /usr/local/go-1.21.0/src/runtime/mgc.go:1385 +0x6f fp=0x7f9636366ed0
> sp=0x7f9636366e80 pc=0x4208af
> runtime.systemstack()
> /usr/local/go-1.21.0/src/runtime/asm_amd64.s:509 +0x4a fp=0x7f9636366ee0
> sp=0x7f9636366ed0 pc=0x46b1aa
>
>
> From the docs, I understand this 2nd pass stop-the-world verification
> guarantees the concurrent mark step did not follow the pointer, aka this is a
> GC bug?
>
> A confirmation would be greatly appreciated to help me follow the right trail.
>
> Context
> I'm building a type-system on top of Go for user-defined data structures. For
> efficient implementation, I'm using unsafe.Pointer-s heavily. I believe I
> understand pointer conversion rules, span classes, that there is metadata on
> the side to differentiate ordinary values from pointers and how it is used to
> follow pointer chains.
> Go vet detects no issues. I've been debugging this for 4 days.
That error looks like the GC found a pointer to an object that was
already freed. This can happen, for example, if you convert a uintptr
to a pointer type, but the object to which the pointer points has been
freed. While it could be a GC bug, that would not be my first guess.
The contents of the block shown above are intended to help you
identify where the pointer came from.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX%3DD6WOoLhsjWTnQqJyAAzYTW03qV56nzKLijSJZOSuwA%40mail.gmail.com.
Re: [go-nuts] Why is reflect.Type defined as an interface, but reflect.Value is defined as a struct?
On Thu, Aug 17, 2023 at 10:02 AM Hu Jian wrote: > > I'm curious why reflect.Type is defined as an interface, but reflect.Value is > defined as a struct? I don't see any other implementation of the reflect.Type > interface. reflect.Value is an ordinary struct. The reflect.Type interface is really implemented by several different types, each of which begins with the same struct but is then followed by type-specific information. On tip this is abi.PointerType, abi.StructType, and so forth. That data structure can in turn be followed by abi.UncommonType. So we have several possible implementations for reflect.Type, although they all exist in the reflect package. Also reflect.Value is small enough to pass around as a value, rather than taking a pointer and sometimes forcing the Value into the heap There's no reason to do that for reflect.Type, as we are normally using pointers to data structures created by the compiler, not data structures in the heap. I think it's true that we could today push everything into a single struct, and do all the pointer conversions behind the scenes, but it wouldn't help much, and we can't make that change today anyhow. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWUvj5kkw6wUeMneGyEqh8MRZXO3CLd5Oz6rSY_z%2BhYuQ%40mail.gmail.com.
Re: [go-nuts] why the go install package download from official website of go1.21 is less than go1.20?
I think that for 1.21 the biggest difference is that we aren't including debug info with the binaries in $GOROOT/pkg/tool/$GOOS_$GOARCH. That change was made in https://go.dev/cl/475378. Ian Ian On Wed, Aug 16, 2023 at 12:46 PM Jeremy Cattone wrote: > > Looks like on-going work, finally completed in 1.21? > > https://github.com/golang/go/issues/27151 > On Tuesday, August 15, 2023 at 9:31:41 PM UTC-7 Kurtis Rader wrote: >> >> All of the packages are significantly smaller -- not just those for macOS. >> So this isn't due to anything specific to the macOS package(s). Looking at >> the release notes for Go 1.21.0 I don't see an obvious explanation for the >> reduction. Downloading and extracting those two packages shows the contents >> have a proportional size difference: >> >> > du -sh go1.20.7/ go1.21.0/ >> 264M go1.20.7/ >> 237M go1.21.0/ >> >> >> Most of the files and directories are larger in the 1.21.0 release. There >> are some notable exceptions. The main one, accounting for most of the >> decrease, is the tool directory: This is the `df -k` diff: >> >> < 111520./pkg/tool/darwin_arm64 >> --- >> > 80704 ./pkg/tool/darwin_arm64 >> >> >> That is a 3 MB reduction (28%) in the total size of the Go tools. Why are >> the Go tools so much smaller? I don't see an obvious answer in the release >> notes. >> >> >> On Tue, Aug 15, 2023 at 8:49 PM xie cui wrote: >>> >>> >>> go1.20.7.darwin-arm64.tar.gzArchivemacOSARM6492MB >>> >>> go1.21.0.darwin-arm64.tar.gzArchivemacOSARM6462MB >>> this size reduce about 30%. >>> why the size reduce a lot? >>> >>> -- >>> 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. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/67bb5470-0b40-4a33-9d11-fefa7f6fd7a6n%40googlegroups.com. >> >> >> >> -- >> Kurtis Rader >> Caretaker of the exceptional canines Junior and Hank > > -- > 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/90e15ffe-a72c-4714-9c66-798bb0ddab70n%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/CAOyqgcW4VRgXp%3DV5UJ_QN2xxQ9kM26Zswn77iQUjnqB5KSvTrQ%40mail.gmail.com.
Re: [go-nuts] cgo pam module signal handling
On Mon, Aug 14, 2023 at 4:52 PM Chandrasekhar R wrote: > > The scenario is: > 1) sudo starts and sets up a signal handler for SIGCHLD > 2) pam modules gets loaded > 3) Go gets initialized and sets the SA_ONSTACK flag specifically by calling > rt_sigaction with a pointer to the existing signal handler in sa_handler > field. > 4) Sudo initialized a new signal handler for SIGCHLD > 5) After the command is run and SIGCHLD signal is received by a Go created > thread instead of the parent sudo thread then it goes to the signal handler > created in step 1. > > I believe this is the current set of events happening. I can share a strace > dump if it would help. Thanks for the outline. That series of events doesn't make sense to me. Signal handlers are process-wide. When in step 4 sudo sets a signal handler for SIGCHLD, that is the signal handler for all threads in the process. When in step 5 a SIGCHLD signal is received, it will go to the signal handler installed in step 4, not the signal handler installed in step 1. Yes, an strace dump would help clarify this. Thanks. Ian > On Monday, August 14, 2023 at 12:17:34 PM UTC-7 Ian Lance Taylor wrote: >> >> On Mon, Aug 14, 2023 at 12:02 PM Chandrasekhar R wrote: >> > >> > My understanding currently is sudo sets up a signal handler in pre_exec >> > and another signal handler later on which is tied into its main event loop. >> > Go gets initialized when the pre_exec signal handler is used and it adds >> > rt_sigaction(SIGCHLD..) with the SA_ONSTACK flag as mentioned here. >> > Then after the sudo command (echo) gets executed, the SIGCHLD is received >> > by one of the go threads which then runs the pre_exec signal handler which >> > is the old and nonexistent signal handler. >> > >> > My approach is to block the Go threads from receiving the SIGCHLD signal >> > and thus not let the signal to be handled by the old signal handler. >> >> I don't quite understand the scenario you are describing. What >> matters is the signal handler. When Go adds the SA_ONSTACK flag, it >> doesn't change the signal handler. Which thread a signal is delivered >> to does not affect which signal handler gets run. >> >> Ian >> >> >> > On Friday, August 11, 2023 at 10:05:48 PM UTC-7 Ian Lance Taylor wrote: >> >> >> >> On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R >> >> wrote: >> >> > >> >> > I am planning on using a pam module written in Go (specifically >> >> > https://github.com/uber/pam-ussh) . When I run a script which calls >> >> > sudo continuously with an echo command, I am noticing zombie/defunct >> >> > processes starting to pop up. >> >> > >> >> > On doing strace, I noticed that the SIGCHLD gets delivered to one of >> >> > the threads created when Go gets initialized (i.e. the shared object >> >> > gets loaded). >> >> > >> >> > I tried to add one level of indirection by having a separate C code >> >> > which creates a new thread, sets the signal mask to block SIGCHLD and >> >> > then use dlopen to open the shared object created using cgo. I am still >> >> > facing the same issue, is there any pointer on how to fix this issue? I >> >> > think this would be a wide issue across all PAM modules written using >> >> > cgo. >> >> >> >> As far as I know the specific thread that receives a SIGCHLD signal is >> >> fairly random. What matters is not the thread that receives the >> >> signal, but the signal handler that is installed. Signal handlers are >> >> process-wide. What signal handler is running when you get a SIGCHLD? >> >> What signal handler do you expect to run? >> >> >> >> 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...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/golang-nuts/7b395394-da12-4b19-9e07-5c8f7e91dcabn%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/216fb89f-ba9c-41e6-ba90-485b9174a0a5n%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/CAOyqgcXc77NmzV8q623MR-1nCm1_5UaO-7tOS5BDM9_%2BX381Qw%40mail.gmail.com.
Re: [go-nuts] epoll: why write 1 byte to the pipe in netpollBreak() and read up to 16 bytes in netpoll()?
On Mon, Aug 14, 2023 at 11:28 AM metronome wrote: > > >> If several different goroutines decide to wake up the polling > >> goroutine before the polling goroutine wakes up, they will each write > >> a single byte > > Wondering, with the introduction of "netpollWakeSig", does it still hold > true? Thanks. Good point, I think you're right. With netpollWakeSig we shouldn't expect to see more than a single byte written to the pipe. Doesn't hurt to try to read more bytes, though. Ian > On Tuesday, July 11, 2023 at 9:00:36 AM UTC+8 Ian Lance Taylor wrote: >> >> On Mon, Jul 10, 2023 at 6:10 AM shaouai wrote: >> > >> > In the implementation of the Go netpoller, `netpollBreak()` attempts to >> > write 1 byte to `netpollBreakWr`, whereas `netpoll()` reads up to 16 bytes >> > from `netpollBreakRd`, why 16 bytes rather than 1 byte? >> > >> > write up to 1 byte: >> > https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=77;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b >> > >> > read up to 16 bytes: >> > https://cs.opensource.google/go/go/+/refs/tags/go1.20.5:src/runtime/netpoll_epoll.go;l=146;drc=c7cc2b94c63af610a29b1b48cfbfb87cb8abf05b >> >> A single byte will wake up a goroutine sleeping in netpoll, so there >> is no reason to write more than one byte. >> >> If several different goroutines decide to wake up the polling >> goroutine before the polling goroutine wakes up, they will each write >> a single byte, and they will all be satisfied by a single wakeup. >> And, if we don't read all those bytes, there will still be bytes in >> the pipe and we'll wake up the next time around the poll loop even if >> we don't have to. So we try to read all of their wakeup bytes at >> once. The number 16 is arbitrary, based on the assumption that it's >> not all that likely that more than 16 goroutines will try to wake up >> the poller simultaneously. >> >> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/8a3ae80e-1e78-441d-8c9a-c99e94e3c2c9n%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/CAOyqgcV_NZfFCG8wkcKd%3DGmev-Vsi4mTD4ECdh%3DRdeVRDyWAeg%40mail.gmail.com.
Re: [go-nuts] cgo pam module signal handling
On Mon, Aug 14, 2023 at 12:02 PM Chandrasekhar R wrote: > > My understanding currently is sudo sets up a signal handler in pre_exec and > another signal handler later on which is tied into its main event loop. > Go gets initialized when the pre_exec signal handler is used and it adds > rt_sigaction(SIGCHLD..) with the SA_ONSTACK flag as mentioned here. > Then after the sudo command (echo) gets executed, the SIGCHLD is received by > one of the go threads which then runs the pre_exec signal handler which is > the old and nonexistent signal handler. > > My approach is to block the Go threads from receiving the SIGCHLD signal and > thus not let the signal to be handled by the old signal handler. I don't quite understand the scenario you are describing. What matters is the signal handler. When Go adds the SA_ONSTACK flag, it doesn't change the signal handler. Which thread a signal is delivered to does not affect which signal handler gets run. Ian > On Friday, August 11, 2023 at 10:05:48 PM UTC-7 Ian Lance Taylor wrote: >> >> On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R wrote: >> > >> > I am planning on using a pam module written in Go (specifically >> > https://github.com/uber/pam-ussh) . When I run a script which calls sudo >> > continuously with an echo command, I am noticing zombie/defunct processes >> > starting to pop up. >> > >> > On doing strace, I noticed that the SIGCHLD gets delivered to one of the >> > threads created when Go gets initialized (i.e. the shared object gets >> > loaded). >> > >> > I tried to add one level of indirection by having a separate C code which >> > creates a new thread, sets the signal mask to block SIGCHLD and then use >> > dlopen to open the shared object created using cgo. I am still facing the >> > same issue, is there any pointer on how to fix this issue? I think this >> > would be a wide issue across all PAM modules written using cgo. >> >> As far as I know the specific thread that receives a SIGCHLD signal is >> fairly random. What matters is not the thread that receives the >> signal, but the signal handler that is installed. Signal handlers are >> process-wide. What signal handler is running when you get a SIGCHLD? >> What signal handler do you expect to run? >> >> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7b395394-da12-4b19-9e07-5c8f7e91dcabn%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/CAOyqgcWhtpjyXALJoMFVjVWkfA4kntsxjKbK-LJxoSzJ9z%2BLAw%40mail.gmail.com.
Re: [go-nuts] How to Create Dynamically Linked Go Programs Redux
On Sat, Aug 12, 2023 at 10:27 AM jlfo...@berkeley.edu
wrote:
>
> Thanks.
>
> There's a more fundamental problem, though. Try running
>
> go build -linkshared hello.go
>
> as a non-privileged user. You'll get a bunch of permission denied messages.
> (I had mentioned this
> back in January). This is why I'm fooling around running the compiler and
> linker manually.
>
> I suggest you add this to your test suite.
To be clear, I ran all the commands I listed as a non-privileged user.
It's not clear why you are running any of the commands as root.
Ian
> On Friday, August 11, 2023 at 10:00:12 PM UTC-7 Ian Lance Taylor wrote:
>>
>> On Fri, Aug 11, 2023 at 6:15 PM jlfo...@berkeley.edu
>> wrote:
>> >
>> > Now that Go 1.21 has been released, I've returned to trying to figure out
>> > how to
>> > dynamically link a Go program. Back in January I posted the results of my
>> > first attempt
>> > with an earlier version of Go, which was:
>> >
>> > 1) Building a Go shared library by running
>> >
>> > go install -buildmode=shared std
>> >
>> > as root works fine.
>> >
>> > 2) Building a dynamically linked Go executable as a non-privileged user by
>> > adding
>> >
>> > -linkshared
>> >
>> > to "go build" fails with lots of file access permission errors because
>> > the go build tool tries to write to the Go shared library, which a
>> > non-privileged
>> > user can't do.
>> >
>> > 3) Building a dynamically link Go executable as root works but a new
>> > version
>> > of the Go shared library gets made in the process. This makes this command
>> > take much longer than it should. Plus, having to be root is a non-starter.
>> >
>> > I started looking at what "go build" is doing by adding the "-x" option.
>> > I was able to figure out how to build and link the following program
>> >
>> > package main
>> > func main() {
>> > }
>> >
>> > using a shared library. This was quite an accomplishment. But, then I
>> > tried making it into
>> > a "Hello, world!" program.
>> >
>> > package main
>> > import "fmt"
>> > func main() {
>> > fmt.Println("Hello, world!\n")
>> > }
>> >
>> > This also compiles and links, but running it results in
>> >
>> > panic: runtime error: invalid memory address or nil pointer dereference
>> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0
>> > pc=0x7fe02814e593]
>> >
>> > goroutine 1 [running]:
>> > os.(*File).write(...)
>> > /usr/local/go/src/os/file_posix.go:46
>> > os.(*File).Write(0x0, {0xc0003a6000?, 0xf, 0x7fe028059f25?})
>> > /usr/local/go/src/os/file.go:183 +0x53
>> > fmt.Fprintln({0x202f88, 0x0}, {0xc00035af20, 0x1, 0x1})
>> > /usr/local/go/src/fmt/print.go:305 +0x6f
>> > fmt.Println(...)
>> > /usr/local/go/src/fmt/print.go:314
>> >
>> > To compile the program I ran
>> >
>> > WORK=/tmp/go-build3183434751
>> > /usr/local/go/pkg/tool/linux_amd64/compile -p main -complete
>> > -installsuffix dynlink -goversion go1.21.0 -c=3 -dynlink -linkshared
>> > -nolocalimports -importcfg $WORK/b001/importcfg ./file1.go
>> >
>> > and to link it I ran
>> >
>> > WORK=/tmp/go-build3183434751
>> > /usr/local/go/pkg/tool/linux_amd64/link -o a.out -importcfg
>> > $WORK/b001/importcfg.link -buildmode=exe -linkshared -w file1.o
>> >
>> > $WORK/b001/importcfg is
>> > packagefile fmt=/usr/local/go/pkg/linux_amd64_dynlink/fmt.a
>> > packagefile runtime=/usr/local/go/pkg/linux_amd64_dynlink/runtime.a
>> > packagefile runtime/cgo=/usr/local/go/pkg/linux_amd64_dynlink/runtime/cgo.a
>> >
>> > $WORK/b001/importcfg.link is many lines like
>> > packagefile fmt=/usr/local/go/pkg/linux_amd64_dynlink/fmt.a
>> > packageshlib fmt=/usr/local/go/pkg/linux_amd64_dynlink/libstd.so
>> >
>> > Both these files were created when I ran the regular "go build
>> > -linkedshare" command.
>> > I have to admit that I don't really understand what these files should
>> > contain,
>> > and I wouldn't be surprised if this is what's causing my problem.
>> >
>> > Any suggestions for what I'm doing wrong?
>>
>> Thanks. This looks like a bug. Somehow we must not be testing quite
>> this case in our -buildmode=shared testsuite.
>>
>> I opened https://go.dev/issue/61973.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b644a419-b3a7-4021-9e1c-b8954e07000cn%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/CAOyqgcU-8d205nmt1bxWuO3tffrzN4336y73yVH5GEGCOsNPQA%40mail.gmail.com.
Re: [go-nuts] cgo pam module signal handling
On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R wrote: > > I am planning on using a pam module written in Go (specifically > https://github.com/uber/pam-ussh) . When I run a script which calls sudo > continuously with an echo command, I am noticing zombie/defunct processes > starting to pop up. > > On doing strace, I noticed that the SIGCHLD gets delivered to one of the > threads created when Go gets initialized (i.e. the shared object gets loaded). > > I tried to add one level of indirection by having a separate C code which > creates a new thread, sets the signal mask to block SIGCHLD and then use > dlopen to open the shared object created using cgo. I am still facing the > same issue, is there any pointer on how to fix this issue? I think this would > be a wide issue across all PAM modules written using cgo. As far as I know the specific thread that receives a SIGCHLD signal is fairly random. What matters is not the thread that receives the signal, but the signal handler that is installed. Signal handlers are process-wide. What signal handler is running when you get a SIGCHLD? What signal handler do you expect to run? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVEwqeoRZ9LLvErxC0rkFcRa9UUYbHSFawDoc%3DuhmTsRA%40mail.gmail.com.
Re: [go-nuts] How to Create Dynamically Linked Go Programs Redux
On Fri, Aug 11, 2023 at 6:15 PM jlfo...@berkeley.edu
wrote:
>
> Now that Go 1.21 has been released, I've returned to trying to figure out how
> to
> dynamically link a Go program. Back in January I posted the results of my
> first attempt
> with an earlier version of Go, which was:
>
> 1) Building a Go shared library by running
>
> go install -buildmode=shared std
>
> as root works fine.
>
> 2) Building a dynamically linked Go executable as a non-privileged user by
> adding
>
> -linkshared
>
> to "go build" fails with lots of file access permission errors because
> the go build tool tries to write to the Go shared library, which a
> non-privileged
> user can't do.
>
> 3) Building a dynamically link Go executable as root works but a new version
> of the Go shared library gets made in the process. This makes this command
> take much longer than it should. Plus, having to be root is a non-starter.
>
> I started looking at what "go build" is doing by adding the "-x" option.
> I was able to figure out how to build and link the following program
>
> package main
> func main() {
> }
>
> using a shared library. This was quite an accomplishment. But, then I tried
> making it into
> a "Hello, world!" program.
>
> package main
> import "fmt"
> func main() {
> fmt.Println("Hello, world!\n")
> }
>
> This also compiles and links, but running it results in
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7fe02814e593]
>
> goroutine 1 [running]:
> os.(*File).write(...)
> /usr/local/go/src/os/file_posix.go:46
> os.(*File).Write(0x0, {0xc0003a6000?, 0xf, 0x7fe028059f25?})
> /usr/local/go/src/os/file.go:183 +0x53
> fmt.Fprintln({0x202f88, 0x0}, {0xc00035af20, 0x1, 0x1})
> /usr/local/go/src/fmt/print.go:305 +0x6f
> fmt.Println(...)
> /usr/local/go/src/fmt/print.go:314
>
> To compile the program I ran
>
> WORK=/tmp/go-build3183434751
> /usr/local/go/pkg/tool/linux_amd64/compile -p main -complete -installsuffix
> dynlink -goversion go1.21.0 -c=3 -dynlink -linkshared -nolocalimports
> -importcfg $WORK/b001/importcfg ./file1.go
>
> and to link it I ran
>
> WORK=/tmp/go-build3183434751
> /usr/local/go/pkg/tool/linux_amd64/link -o a.out -importcfg
> $WORK/b001/importcfg.link -buildmode=exe -linkshared -w file1.o
>
> $WORK/b001/importcfg is
> packagefile fmt=/usr/local/go/pkg/linux_amd64_dynlink/fmt.a
> packagefile runtime=/usr/local/go/pkg/linux_amd64_dynlink/runtime.a
> packagefile runtime/cgo=/usr/local/go/pkg/linux_amd64_dynlink/runtime/cgo.a
>
> $WORK/b001/importcfg.link is many lines like
> packagefile fmt=/usr/local/go/pkg/linux_amd64_dynlink/fmt.a
> packageshlib fmt=/usr/local/go/pkg/linux_amd64_dynlink/libstd.so
>
> Both these files were created when I ran the regular "go build -linkedshare"
> command.
> I have to admit that I don't really understand what these files should
> contain,
> and I wouldn't be surprised if this is what's causing my problem.
>
> Any suggestions for what I'm doing wrong?
Thanks. This looks like a bug. Somehow we must not be testing quite
this case in our -buildmode=shared testsuite.
I opened https://go.dev/issue/61973.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVLSrU7guvgeWmN8OeFi3pz%2BnRyaZj-Ehu%2BQt9wppAqxg%40mail.gmail.com.
Re: [go-nuts] What does "shallow clone" mean?
On Fri, Aug 11, 2023, 7:28 AM shinya sakae wrote: > maps package was released with Go 1.21. > Clone() comment says "This is a shallow clone". > I often hear the term `shallow copy', but I don't know what `shallow > clone` means. > What is the state of a `shallow cloned` map? > Do you mean that the cloned map values are shallow copied? Yes. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXQ3gR8%3D1EO_M_HW6Dqrs5%3DuXxyPjnwmBkWcTUk-OKKRA%40mail.gmail.com.
Re: [go-nuts] What happened to sep in errorrs.join
[ + jba ]
On Tue, Aug 8, 2023 at 4:24 AM Joseph Lorenzini wrote:
>
> Thanks that was very helpful. As for your point about slog, yes a custom
> handler could but I am using the library json handler.
>
> I suppose the proper way to frame my problem is that I am using the slog
> library handler and I do not want new lines in the message or keys.
>
> Would the go team would be open to providing knobs to control how the handler
> does formatting? I assumed if I tried opening a proposal like that I’d be
> told to write a custom handler. :)
>
> On Mon, Aug 7, 2023 at 3:56 PM Ian Lance Taylor wrote:
>>
>> On Mon, Aug 7, 2023 at 4:32 AM jal...@gmail.com wrote:
>> >
>> > In the errors.join proposal, the proposed api had the user specify how
>> > they wanted the errors to be formatted together. But the actual
>> > implementation omitted and only used new line.
>> >
>> > This is quite unfortunate if you are using slog and want to log that error
>> > and very much need a log statement to not span multiple lines. It also
>> > makes it much harder to read.
>> >
>> > Does anyone recall why sep was dropped?
>>
>> See the discussion at https://go.dev/issue/53435, especially
>> https://github.com/golang/go/issues/53435#issuecomment-1190654775 and
>> https://github.com/golang/go/issues/53435#issuecomment-1190845424.
>>
>> As far as the slog package it seems to me that a handler can enforce
>> that individual messages are on a single line. There may be a better
>> way to address that problem, but I don't think that errors.Join is the
>> right place for a fix. Any random package can generate multiline
>> error messages with errors.New("a\nb"), and I've seen plenty that do.
>> So enforcing single-line messages on errors.Join won't fix the problem
>> in general.
>>
>> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVRUUrjkX5owdhW-Y-_yc2QsD0ajK%3D-ccMrHU3NxTLidw%40mail.gmail.com.
Re: [go-nuts] What happened to sep in errorrs.join
On Mon, Aug 7, 2023 at 4:32 AM jal...@gmail.com wrote:
>
> In the errors.join proposal, the proposed api had the user specify how they
> wanted the errors to be formatted together. But the actual implementation
> omitted and only used new line.
>
> This is quite unfortunate if you are using slog and want to log that error
> and very much need a log statement to not span multiple lines. It also makes
> it much harder to read.
>
> Does anyone recall why sep was dropped?
See the discussion at https://go.dev/issue/53435, especially
https://github.com/golang/go/issues/53435#issuecomment-1190654775 and
https://github.com/golang/go/issues/53435#issuecomment-1190845424.
As far as the slog package it seems to me that a handler can enforce
that individual messages are on a single line. There may be a better
way to address that problem, but I don't think that errors.Join is the
right place for a fix. Any random package can generate multiline
error messages with errors.New("a\nb"), and I've seen plenty that do.
So enforcing single-line messages on errors.Join won't fix the problem
in general.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV%3D1QeVeiJnaVZadNN8Mg2YVsb3oLeUTay%2Bm6dJ9PHhQQ%40mail.gmail.com.
Re: [go-nuts] Why is type inference still so rudimentary?
On Fri, Aug 4, 2023 at 8:08 AM Nate Finch wrote:
>
> If I have a struct
>
> type User struct {
> Name string
> ID int
> }
>
> type Group struct {
> Leader User
> }
>
> Why is it that the go tool can't infer what type I'm constructing for the
> Leader field here?
>
> g := Group{
> Leader: {
>Name: "Jamie",
>ID: 5,
> },
> }
>
> Cleary, the compiler knows I'm constructing a variable of type Group, and
> thus should know that Leader: is a field in Group, and thus what type I am
> constructing to assign to that field. It's not like it's an interface where
> I could be assigning anything.
>
> Finally, why does this work with maps, but not struct fields?
>
> users := map[string]User {
> "Jamie" : {
>Name: "Jamie",
>ID: 5,
> },
> }
>
> This works and feels almost identical to the Group code above. Define the
> enclosing type, and then the subtype is obvious and thus implicit.
>
> I presume this is some parser thing where it can't distinguish between two
> possible valid constructions, though I can't think of exactly what other
> construction it might mean
I think this is https://go.dev/issue/12854. At least that is related.
The reason we don't do it today boils down to: we implemented it in
gofmt -s and weren't really happy with how it looked. A number of
existing composite literals became nearly unreadable when the types
were omitted. They were just collections of braces and elements, and
it was hard to tell what they meant. That was a long time ago and we
may feel differently now, if somebody wants to seriously investigate.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVTbE%3DxqDDO64d5ZOXD7VgOcNf0WzZzNP5T_esJ6HTP1Q%40mail.gmail.com.
Re: [go-nuts] go11tag
On Fri, Jul 28, 2023 at 9:55 AM John Pritchard wrote: > > Debugging "go build" with dlv, which hungup at > > go/src/cmd/go/main.go:92:var _ = go11tag > > Looking around a bit, found no particular rationale for the existence of > "go11tag". It's a small test. See the comment on the definition in cmd/go/go11.go. We can probably get rid of it now. But it also shouldn't cause any problem with Delve. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWLMpcqH0AaPRe0i%3Du73mzLhY7NbukAqbA6X-L2SD%2BqYQ%40mail.gmail.com.
Re: [go-nuts] error handling thoughts
On Thu, Jul 27, 2023 at 8:04 AM Steve Roth wrote:
>
> In those cases, what I'd like to write is
>
> if result, err := fn(); err != nil {
>
> // handle error and bail out
>
> } else {
>
> // act on result
> }
>
>
> Unfortunately, the compiler gives a warning on that.
As others have pointed out, the compiler does not give such an error.
The error must be coming from some other tool. If you tell us what
tool that is, perhaps we can fix it. In general a tool should not
recommend removing the else clause from an if statement with a simple
statement that declares variables if the else clause refers to any of
those variables.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUSEXDinAw_cHEE-SJ8z-feAC2LPwXZESVe03tmFfMYbw%40mail.gmail.com.
Re: [go-nuts] Re: Possible Go Compiler or Runtime bug?
On Thu, Jul 27, 2023 at 3:17 PM 'Michael Knyszek' via golang-nuts wrote: > > The number 32 for the capacity comes from this constant, and the returned > byte slice in that case is likely coming from a compiler-inserted call to > stringtoslicebyte. An empty string is correctly replaced by a zero-length > byte slice, it just so happens that the capacity of the array backing that > slice may or may not be zero. As Brian said, commenting or uncommenting that > line likely just leads to the byte slice's backing array being allocated > differently. > > I believe this is working as intended, because I don't think the spec makes > any guarantees about the capacity of the slice you get back from a > conversion. On the one hand, it is a little surprising given that the make > builtin very explicitly sets the capacity of the slice. On the other hand, > append is an example of a built-in that may return a slice with a larger > capacity than requested, so it's not like this case is the only outlier. I agree that this is not a bug. The language makes no promises about the capacity of the slice returned by a string to []byte conversion. The comment in the code //this crashes, panics because capacity is 0, even though I can access all 32 bytes in the loop above is misleading. In the case that crashes, the program can't access all 32 bytes in the loop above. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWV%3D-g9m8A_EhLnTyuK0x2ffkgDP5wCJtPKG%3DWkM77FUg%40mail.gmail.com.
Re: [go-nuts] go package dating back to 2009
On Tue, Jul 25, 2023 at 3:29 PM Bravo Moua wrote: > > How bout prior to the public release in nov 2009? Well here's the story, Im > looking for the creator of Bitcoin, I was a part of the creation of Bitcoin > from the beginning. We ve coded some codes in Golang in Jan 2009. Just asking > around if there is any history that is prior to the release of golang in Nov > 2009 that can be found by who created the packages then. For a fact, bytes, > fmt, and packages in those category are from Satoshi Nakamoto and myself. > Just looking for a old friend. It seems quite unlikely that there was any Bitcoin code written in Go in January, 2009. I was working on Go at that time, and I never heard a hint of anything like that. At that time all Go code was written by people at Google, and there was very very little of it. You can see approximately all of it in the git repository at go.googlesource.com (the Go team was not using git at the time, but the revision history was copied into git later). It is not completely impossible that somebody at Google wrote some Bitcoin code in Go before November, 2009, and that I never heard about it, but I'm pretty skeptical. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVUxRocqSqRrh6TG9bEuNsn%3D9BUsatMAZ4BGA06UVF%2BCg%40mail.gmail.com.
Re: [go-nuts] go package dating back to 2009
On Mon, Jul 24, 2023 at 3:08 PM Bravo Moua wrote: > > How can one search for packages dating back to Jan 2009 Well, Go was only publicly released in November, 2009, so there are no public Go packages as old as January, 2009. I assume you know that you can search for Go packages today at https://pkg.go.dev/. Perhaps if you clarify what you are looking for we can provide a more useful answer. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUWjeRXbrcKtM6j0mV6ZfaSk6o8q6u3fn7Xityk8b3fJA%40mail.gmail.com.
Re: [go-nuts] [net.mail] ReadMessage returns nil, io.EOF when email w/o body.
On Tue, Jul 18, 2023 at 4:36 PM Karan Gupta wrote: > > RFC 5322 (https://www.rfc-editor.org/rfc/rfc5322#section-3.5) allows for > messages without bodies. > ` A message consists of header fields, optionally followed by a message body ` > > However, the net/mail . ReadMessage returns an error when an email does not > contain a body. > To demonstrate this I have written a small program (attached) that shows the > difference in values returned by mail.ReadMessage when the input email > message ends in > 1. a 'field' where field is defined as in RFC5322. with focus on the fact > that 'field' ends in a single CRLF > 2. a body. In this specific case, I have chosen to use an empty body. Email > is constructed by appending 2 consecutive CRLFs to the message from (1). The > first CRLF is to separate the header from the body and the second to > terminate an empty body > > Is this a bug in the go standard library? I think you are describing https://go.dev/issue/33823, which, as it happens, is fixed in the upcoming Go 1.21 release. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW_MRGDG%3Dq832pO69gjVA9MXY5sEF_dRz-LP3SYTrQ8Ag%40mail.gmail.com.
