[go-nuts] Re: TLS negotiation bug in go1.21.4?

[Shifeng Song]

hello, curious if you were able to resolve the issue by downgrading golang? 
im having the exact same issue as you causing TLS handshakes to fail

On Thursday, January 11, 2024 at 8:06:16 AM UTC+8 Andrew Athan wrote:

> I tried go1.21.6 and see the same behavior. I'm going to try to backport 
> the project to go1.18 to see what happens.
>
> On Wednesday, January 10, 2024 at 3:51:16 PM UTC-8 Andrew Athan wrote:
>
>> As you can see in the below output from pprof, the golang TLS 
>> implementation seems to be in some kind of tight loop in 
>> crypto/internal/bigmod.addMulVVW2048 causing CPU starvation, wherein the 
>> net.HTTP server stops calling my request handler. Eventually the TLS 
>> handshakes fail, and the connections are dropped before my handler ever 
>> sees them. I guess I'll look for an even newer version of golang, but 
>> wanted to post this here to see if you have any feedback. It seems unlikely 
>> to me that go's TLS package would exhibit this type of regression.
>>
>> $ go tool pprof /tmp/cpu.prof2
>> File: sgs-server-dev
>> Type: cpu
>> Time: Jan 10, 2024 at 10:10pm (UTC)
>> Duration: 180.20s, Total samples = 892.25s (495.14%)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) top 10
>> Showing nodes accounting for 840.73s, 94.23% of 892.25s total
>> Dropped 1278 nodes (cum <= 4.46s)
>> Showing top 10 nodes out of 52
>>   flat  flat%   sum%cum   cum%
>>595.80s 66.78% 66.78%595.80s 66.78% 
>>  crypto/internal/bigmod.addMulVVW2048
>> 83.10s  9.31% 76.09%772.62s 86.59% 
>>  crypto/internal/bigmod.(*Nat).montgomeryMul
>> 53.66s  6.01% 82.10% 53.86s  6.04% 
>>  crypto/internal/bigmod.(*Nat).assign (inline)
>> 42.83s  4.80% 86.90% 42.93s  4.81% 
>>  crypto/internal/bigmod.addMulVVW (inline)
>> 23.23s  2.60% 89.51% 25.10s  2.81% 
>>  crypto/internal/bigmod.(*Nat).shiftIn
>> 14.93s  1.67% 91.18% 14.93s  1.67% 
>>  crypto/internal/bigmod.(*Nat).sub (inline)
>>  7.75s  0.87% 92.05%  7.75s  0.87%  runtime.memmove
>>  7.33s  0.82% 92.87%  7.33s  0.82%  runtime.duffzero
>>  7.12s   0.8% 93.67%  7.12s   0.8% 
>>  runtime/internal/syscall.Syscall6
>>  4.98s  0.56% 94.23%  4.98s  0.56%  crypto/sha256.block
>>
>> I am building an executable on this box:
>>
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description: Ubuntu 23.04
>> Release: 23.04
>> Codename: lunar
>>
>> $ uname -a
>> Linux AASalad 6.2.0-36-generic #37-Ubuntu SMP PREEMPT_DYNAMIC Wed Oct  4 
>> 10:14:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
>>
>> $ go version
>> go version go1.21.4 linux/amd64
>>
>> Using this command:
>>
>> GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o a.out -buildvcs=true -a 
>> -ldflags '-extldflags "-static"'
>>
>> This executable is then deployed to a Debian 11 host:
>>
>> # lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Debian
>> Description: Debian GNU/Linux 11 (bullseye)
>> Release: 11
>> Codename: bullseye
>>
>> # uname -a
>> Linux sgs-dandelion 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) 
>> x86_64 GNU/Linux
>>
>> This was done because without the -static build, the right glibc so's are 
>> not found on the target system. When running the executable under high 
>> incoming TLS connection load, I observe that the net.HTTP handler is 
>> eventually not called and lots of these errors are logged:
>>
>> http: TLS handshake error from ...
>>
>> with this stacktrace:
>> log.(*Logger).output
>> /usr/local/go/src/log/log.go:245
>> log.(*Logger).Printf
>> /usr/local/go/src/log/log.go:268
>> net/http.(*Server).logf
>> /usr/local/go/src/net/http/server.go:3212
>> net/http.(*conn).serve
>> /usr/local/go/src/net/http/server.go:1900
>>
>> This exe handles high load and lots of incoming TLS connections. I have 
>> exhaustively looked for a source of CPU starvation such as excessive 
>> numbers of goroutines started by my code, or tight loops, etc. and have not 
>> found evidence for that.
>>
>>
>> Here is the output of pprof tree:
>>
>> (pprof) tree
>> Showing nodes accounting for 853.85s, 95.70% of 892.25s total
>> Dropped 1278 nodes (cum <= 4.46s)
>> --+-
>>   flat  flat%   sum%cum   cum%   calls calls% + context
>> --+-
>>595.80s   100% |   
>> crypto/internal/bigmod.(*Nat).montgomeryMul
>>595.80s 66.78% 66.78%595.80s 66.78%| 
>> crypto/internal/bigmod.addMulVVW2048
>> --+-
>>718.77s 93.03% |   
>> crypto/internal/bigmod.(*Nat).Exp
>> 47.75s  6.18% |   
>> crypto/internal/bigmod.(*Nat).ExpShort
>>  4.76s  0.62% |   
>> 

[go-nuts] Re: TLS negotiation bug in go1.21.4?

[Stanley Song]

hello, curious if you were able to resolve the issue by downgrading golang? 
I am having the exact same issue as you with cpu blowing up 
at crypto/internal/bigmod.(*Nat).montgomeryMul causing TLS handshakes to 
fail

On Thursday, January 11, 2024 at 8:06:16 AM UTC+8 Andrew Athan wrote:

> I tried go1.21.6 and see the same behavior. I'm going to try to backport 
> the project to go1.18 to see what happens.
>
> On Wednesday, January 10, 2024 at 3:51:16 PM UTC-8 Andrew Athan wrote:
>
>> As you can see in the below output from pprof, the golang TLS 
>> implementation seems to be in some kind of tight loop in 
>> crypto/internal/bigmod.addMulVVW2048 causing CPU starvation, wherein the 
>> net.HTTP server stops calling my request handler. Eventually the TLS 
>> handshakes fail, and the connections are dropped before my handler ever 
>> sees them. I guess I'll look for an even newer version of golang, but 
>> wanted to post this here to see if you have any feedback. It seems unlikely 
>> to me that go's TLS package would exhibit this type of regression.
>>
>> $ go tool pprof /tmp/cpu.prof2
>> File: sgs-server-dev
>> Type: cpu
>> Time: Jan 10, 2024 at 10:10pm (UTC)
>> Duration: 180.20s, Total samples = 892.25s (495.14%)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) top 10
>> Showing nodes accounting for 840.73s, 94.23% of 892.25s total
>> Dropped 1278 nodes (cum <= 4.46s)
>> Showing top 10 nodes out of 52
>>   flat  flat%   sum%cum   cum%
>>595.80s 66.78% 66.78%595.80s 66.78% 
>>  crypto/internal/bigmod.addMulVVW2048
>> 83.10s  9.31% 76.09%772.62s 86.59% 
>>  crypto/internal/bigmod.(*Nat).montgomeryMul
>> 53.66s  6.01% 82.10% 53.86s  6.04% 
>>  crypto/internal/bigmod.(*Nat).assign (inline)
>> 42.83s  4.80% 86.90% 42.93s  4.81% 
>>  crypto/internal/bigmod.addMulVVW (inline)
>> 23.23s  2.60% 89.51% 25.10s  2.81% 
>>  crypto/internal/bigmod.(*Nat).shiftIn
>> 14.93s  1.67% 91.18% 14.93s  1.67% 
>>  crypto/internal/bigmod.(*Nat).sub (inline)
>>  7.75s  0.87% 92.05%  7.75s  0.87%  runtime.memmove
>>  7.33s  0.82% 92.87%  7.33s  0.82%  runtime.duffzero
>>  7.12s   0.8% 93.67%  7.12s   0.8% 
>>  runtime/internal/syscall.Syscall6
>>  4.98s  0.56% 94.23%  4.98s  0.56%  crypto/sha256.block
>>
>> I am building an executable on this box:
>>
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description: Ubuntu 23.04
>> Release: 23.04
>> Codename: lunar
>>
>> $ uname -a
>> Linux AASalad 6.2.0-36-generic #37-Ubuntu SMP PREEMPT_DYNAMIC Wed Oct  4 
>> 10:14:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
>>
>> $ go version
>> go version go1.21.4 linux/amd64
>>
>> Using this command:
>>
>> GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o a.out -buildvcs=true -a 
>> -ldflags '-extldflags "-static"'
>>
>> This executable is then deployed to a Debian 11 host:
>>
>> # lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Debian
>> Description: Debian GNU/Linux 11 (bullseye)
>> Release: 11
>> Codename: bullseye
>>
>> # uname -a
>> Linux sgs-dandelion 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) 
>> x86_64 GNU/Linux
>>
>> This was done because without the -static build, the right glibc so's are 
>> not found on the target system. When running the executable under high 
>> incoming TLS connection load, I observe that the net.HTTP handler is 
>> eventually not called and lots of these errors are logged:
>>
>> http: TLS handshake error from ...
>>
>> with this stacktrace:
>> log.(*Logger).output
>> /usr/local/go/src/log/log.go:245
>> log.(*Logger).Printf
>> /usr/local/go/src/log/log.go:268
>> net/http.(*Server).logf
>> /usr/local/go/src/net/http/server.go:3212
>> net/http.(*conn).serve
>> /usr/local/go/src/net/http/server.go:1900
>>
>> This exe handles high load and lots of incoming TLS connections. I have 
>> exhaustively looked for a source of CPU starvation such as excessive 
>> numbers of goroutines started by my code, or tight loops, etc. and have not 
>> found evidence for that.
>>
>>
>> Here is the output of pprof tree:
>>
>> (pprof) tree
>> Showing nodes accounting for 853.85s, 95.70% of 892.25s total
>> Dropped 1278 nodes (cum <= 4.46s)
>> --+-
>>   flat  flat%   sum%cum   cum%   calls calls% + context
>> --+-
>>595.80s   100% |   
>> crypto/internal/bigmod.(*Nat).montgomeryMul
>>595.80s 66.78% 66.78%595.80s 66.78%| 
>> crypto/internal/bigmod.addMulVVW2048
>> --+-
>>718.77s 93.03% |   
>> crypto/internal/bigmod.(*Nat).Exp
>> 47.75s  6.18% |   
>> crypto/internal/bigmod.(*Nat).ExpShort
>>   

[go-nuts] Re: TLS negotiation bug in go1.21.4?

[Andrew Athan]

I tried go1.21.6 and see the same behavior. I'm going to try to backport 
the project to go1.18 to see what happens.

On Wednesday, January 10, 2024 at 3:51:16 PM UTC-8 Andrew Athan wrote:

> As you can see in the below output from pprof, the golang TLS 
> implementation seems to be in some kind of tight loop in 
> crypto/internal/bigmod.addMulVVW2048 causing CPU starvation, wherein the 
> net.HTTP server stops calling my request handler. Eventually the TLS 
> handshakes fail, and the connections are dropped before my handler ever 
> sees them. I guess I'll look for an even newer version of golang, but 
> wanted to post this here to see if you have any feedback. It seems unlikely 
> to me that go's TLS package would exhibit this type of regression.
>
> $ go tool pprof /tmp/cpu.prof2
> File: sgs-server-dev
> Type: cpu
> Time: Jan 10, 2024 at 10:10pm (UTC)
> Duration: 180.20s, Total samples = 892.25s (495.14%)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top 10
> Showing nodes accounting for 840.73s, 94.23% of 892.25s total
> Dropped 1278 nodes (cum <= 4.46s)
> Showing top 10 nodes out of 52
>   flat  flat%   sum%cum   cum%
>595.80s 66.78% 66.78%595.80s 66.78% 
>  crypto/internal/bigmod.addMulVVW2048
> 83.10s  9.31% 76.09%772.62s 86.59% 
>  crypto/internal/bigmod.(*Nat).montgomeryMul
> 53.66s  6.01% 82.10% 53.86s  6.04% 
>  crypto/internal/bigmod.(*Nat).assign (inline)
> 42.83s  4.80% 86.90% 42.93s  4.81% 
>  crypto/internal/bigmod.addMulVVW (inline)
> 23.23s  2.60% 89.51% 25.10s  2.81% 
>  crypto/internal/bigmod.(*Nat).shiftIn
> 14.93s  1.67% 91.18% 14.93s  1.67% 
>  crypto/internal/bigmod.(*Nat).sub (inline)
>  7.75s  0.87% 92.05%  7.75s  0.87%  runtime.memmove
>  7.33s  0.82% 92.87%  7.33s  0.82%  runtime.duffzero
>  7.12s   0.8% 93.67%  7.12s   0.8% 
>  runtime/internal/syscall.Syscall6
>  4.98s  0.56% 94.23%  4.98s  0.56%  crypto/sha256.block
>
> I am building an executable on this box:
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 23.04
> Release: 23.04
> Codename: lunar
>
> $ uname -a
> Linux AASalad 6.2.0-36-generic #37-Ubuntu SMP PREEMPT_DYNAMIC Wed Oct  4 
> 10:14:28 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
>
> $ go version
> go version go1.21.4 linux/amd64
>
> Using this command:
>
> GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o a.out -buildvcs=true -a 
> -ldflags '-extldflags "-static"'
>
> This executable is then deployed to a Debian 11 host:
>
> # lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description: Debian GNU/Linux 11 (bullseye)
> Release: 11
> Codename: bullseye
>
> # uname -a
> Linux sgs-dandelion 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) 
> x86_64 GNU/Linux
>
> This was done because without the -static build, the right glibc so's are 
> not found on the target system. When running the executable under high 
> incoming TLS connection load, I observe that the net.HTTP handler is 
> eventually not called and lots of these errors are logged:
>
> http: TLS handshake error from ...
>
> with this stacktrace:
> log.(*Logger).output
> /usr/local/go/src/log/log.go:245
> log.(*Logger).Printf
> /usr/local/go/src/log/log.go:268
> net/http.(*Server).logf
> /usr/local/go/src/net/http/server.go:3212
> net/http.(*conn).serve
> /usr/local/go/src/net/http/server.go:1900
>
> This exe handles high load and lots of incoming TLS connections. I have 
> exhaustively looked for a source of CPU starvation such as excessive 
> numbers of goroutines started by my code, or tight loops, etc. and have not 
> found evidence for that.
>
>
> Here is the output of pprof tree:
>
> (pprof) tree
> Showing nodes accounting for 853.85s, 95.70% of 892.25s total
> Dropped 1278 nodes (cum <= 4.46s)
> --+-
>   flat  flat%   sum%cum   cum%   calls calls% + context
> --+-
>595.80s   100% |   
> crypto/internal/bigmod.(*Nat).montgomeryMul
>595.80s 66.78% 66.78%595.80s 66.78%| 
> crypto/internal/bigmod.addMulVVW2048
> --+-
>718.77s 93.03% |   
> crypto/internal/bigmod.(*Nat).Exp
> 47.75s  6.18% |   
> crypto/internal/bigmod.(*Nat).ExpShort
>  4.76s  0.62% |   
> crypto/internal/bigmod.(*Nat).montgomeryRepresentation
>  1.34s  0.17% |   
> crypto/rsa.decrypt
> 83.10s  9.31% 76.09%772.62s 86.59%| 
> crypto/internal/bigmod.(*Nat).montgomeryMul
>595.80s 77.11% |   
> 

Re: [go-nuts] Re: [rfc] build bug in type abstraction?

[John Pritchard]

Hi Brian,

Thanks for the review.  Your basic conclusion matches mine, that the
./main/main.go:46 and ./types.go are proven in the "go run" case, and
disproven in the "go build" case.

Best,

John


On Wed, Aug 16, 2023 at 9:58 AM Brian Candler  wrote:

> On Wednesday, 16 August 2023 at 14:05:49 UTC+1 John Pritchard wrote:
>
> I have a disparity between "go run" [
> https://go.dev/play/p/5mr5M0luZ9k?v=goprev]
> and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].
> Using go version 1.21.0.
>
>
> I don't quite understand where "go run" comes into this.  In your Makefile
> ,
> both options use "go build".
>
> "make list" is doing something dubious:
>
> go_sources := $(shell ls *.go)
> ...
> list: main/main.go $(go_sources)
> go build -o $@ $<
>
> That is, I think you're trying to compile "main/main.go" and "types.go" at
> the same time into a single object file.  But types.go is "package types"
> whereas main.go is "package main".  That should give you an error; if it
> doesn't, that makes me suspect that go_sources is in fact empty.  The "make
> list" output you show in README.txt appears to confirm this:
>
> $ make
> go build -o list main/main.go# <<< note that no additional sources are
> listed on the command line
>
> In main.go, there is a pretty clear error that the compiler calls out in
> line 46:
> main/main.go:46:15: undefined: Abstract
>
> The corresponding source line
> 
> is:
> var abstract Abstract = types.Init()
>
> and as far as I can see, it's correct: you have no type "Abstract" in
> package main in main.go (in otherwise, you should be referring to
> "types.Abstract")
>
>
> --
> 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/a0716bee-a6b9-4ea7-b4a7-165c4ef43fabn%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/CAD6mcO85tazOOrykPzp0XEg7FRfT7vKDLSk-fevrFm7sxMGaCQ%40mail.gmail.com.

[go-nuts] Re: [rfc] build bug in type abstraction?

[Brian Candler]

On Wednesday, 16 August 2023 at 14:05:49 UTC+1 John Pritchard wrote: 

I have a disparity between "go run" [
https://go.dev/play/p/5mr5M0luZ9k?v=goprev] 
and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].  
Using go version 1.21.0.


I don't quite understand where "go run" comes into this.  In your Makefile 
, both 
options use "go build".

"make list" is doing something dubious:

go_sources := $(shell ls *.go)
...
list: main/main.go $(go_sources)
go build -o $@ $<

That is, I think you're trying to compile "main/main.go" and "types.go" at 
the same time into a single object file.  But types.go is "package types" 
whereas main.go is "package main".  That should give you an error; if it 
doesn't, that makes me suspect that go_sources is in fact empty.  The "make 
list" output you show in README.txt appears to confirm this:

$ make
go build -o list main/main.go# <<< note that no additional sources are 
listed on the command line

In main.go, there is a pretty clear error that the compiler calls out in 
line 46:
main/main.go:46:15: undefined: Abstract

The corresponding source line 
 
is:
var abstract Abstract = types.Init()

and as far as I can see, it's correct: you have no type "Abstract" in 
package main in main.go (in otherwise, you should be referring to 
"types.Abstract")


-- 
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/a0716bee-a6b9-4ea7-b4a7-165c4ef43fabn%40googlegroups.com.

[go-nuts] Re: [rfc] build bug in type abstraction?

[Jason Phillips]

A few things:

* As illustrated by the output in your README, it appears your "make list" 
command is only compiling "main/main.go", rather than both "main/main.go" 
and "main/run.go"
* There can only be one main function per main package in Go, so I'm not 
sure how main/run.go and main/main.go are expected to coexist in a valid Go 
application

On Wednesday, August 16, 2023 at 9:05:49 AM UTC-4 John Pritchard wrote:

> Hi,
>
> I have a disparity between "go run" [
> https://go.dev/play/p/5mr5M0luZ9k?v=goprev] 
> and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].  
> Using go version 1.21.0.
>
> A fairly simple structure of type abstraction works on play.go.dev, but 
> fails to build.
>
> Comments?  Issue?
>
> Thanks,
>
> John
>
>
>

-- 
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/b59e8956-5fdc-41a3-bb3f-87921a685fa6n%40googlegroups.com.

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

[Jinbao Chen]

Thanks for the relpy. I have opened an issue on github: 
https://github.com/golang/go/issues/61730

On Thursday, 3 August 2023 at 17:49:25 UTC+8 Michael Knyszek wrote:

> That line (the full sentence is "The garbage collector now includes 
> non-heap sources of garbage collector work (e.g., stack scanning) when 
> determining how frequently to run.") is unrelated. It only refers to a 
> change in accounting for what gets included in the GOGC calculation, not a 
> change in what was marked and scanned by the GC.
>
> On Thursday, August 3, 2023 at 1:41:35 AM UTC-4 Qingwei Li wrote:
>
>> I notice that Go1.17.7 still allocates the array on heap by calling 
>> newobject while Go1.18 allocates the array on stack. I also notice that in 
>> the release note of Go1.18 that "The garbage collector now includes 
>> non-heap sources of garbage collector work". Does the GC in 1.18 and 
>> following versions of Go ignore some global memory area when marking?
>>
>> On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:
>>
>>> I use go1.20.5 to compile the following code. 
>>> package main
>>>
>>> func use(...interface{}) {
>>>   
>>> }
>>>
>>> func main() {
>>> testCases := [...][][]int{
>>> {{42}},
>>> {{1, 2}},
>>> {{3, 4, 5}},
>>> {{}},
>>> {{1, 2}, {3, 4, 5}, {}, {7}},
>>> }
>>> for _, testCase := range testCases {
>>> use(testCase)
>>> }
>>> }
>>> In the generated SSA and assembly code, I notice that the Go compiler 
>>> generates some instructions that store a stack pointer(point to the 
>>> stack-allocated array) into a global slice header.
>>>
>>> Just like the assembly code below, the MOV instruction at 0x4585bf 
>>> stores a stack pointer into a global object: 
>>>   0x458589 48c7442408   MOVQ $0x0, 0x8(SP) 
>>>   0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP) 
>>> testCases := [...][][]int{
>>>   0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP) 
>>>   0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP) 
>>>   0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB) 
>>>   0x4585b8 750e JNE 0x4585c8 
>>>   0x4585ba 488d442408 LEAQ 0x8(SP), AX 
>>>   0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP) 
>>>   0x4585c6 eb11 JMP 0x4585d9 
>>>   0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI 
>>>   0x4585cf 488d442408 LEAQ 0x8(SP), AX 
>>>   0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB) 
>>>
>>> I have read the comments in slicelit 
>>> ,
>>>   
>>> but I didn't find any operations that can generate such stores. As far as I 
>>> know, pointers to stack objects cannot be stored in global objects. So is 
>>> this a compiler bug? Or the Go compiler does this on purpose to achieve 
>>> some optimization I don't know yet?
>>>
>>> Thanks
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e7fc85da-8df8-43ee-b611-c57cbc142fa9n%40googlegroups.com.

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

['Michael Knyszek' via golang-nuts]

That line (the full sentence is "The garbage collector now includes 
non-heap sources of garbage collector work (e.g., stack scanning) when 
determining how frequently to run.") is unrelated. It only refers to a 
change in accounting for what gets included in the GOGC calculation, not a 
change in what was marked and scanned by the GC.

On Thursday, August 3, 2023 at 1:41:35 AM UTC-4 Qingwei Li wrote:

> I notice that Go1.17.7 still allocates the array on heap by calling 
> newobject while Go1.18 allocates the array on stack. I also notice that in 
> the release note of Go1.18 that "The garbage collector now includes 
> non-heap sources of garbage collector work". Does the GC in 1.18 and 
> following versions of Go ignore some global memory area when marking?
>
> On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:
>
>> I use go1.20.5 to compile the following code. 
>> package main
>>
>> func use(...interface{}) {
>>   
>> }
>>
>> func main() {
>> testCases := [...][][]int{
>> {{42}},
>> {{1, 2}},
>> {{3, 4, 5}},
>> {{}},
>> {{1, 2}, {3, 4, 5}, {}, {7}},
>> }
>> for _, testCase := range testCases {
>> use(testCase)
>> }
>> }
>> In the generated SSA and assembly code, I notice that the Go compiler 
>> generates some instructions that store a stack pointer(point to the 
>> stack-allocated array) into a global slice header.
>>
>> Just like the assembly code below, the MOV instruction at 0x4585bf stores 
>> a stack pointer into a global object: 
>>   0x458589 48c7442408   MOVQ $0x0, 0x8(SP) 
>>   0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP) 
>> testCases := [...][][]int{
>>   0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP) 
>>   0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP) 
>>   0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB) 
>>   0x4585b8 750e JNE 0x4585c8 
>>   0x4585ba 488d442408 LEAQ 0x8(SP), AX 
>>   0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP) 
>>   0x4585c6 eb11 JMP 0x4585d9 
>>   0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI 
>>   0x4585cf 488d442408 LEAQ 0x8(SP), AX 
>>   0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB) 
>>
>> I have read the comments in slicelit 
>> ,
>>   
>> but I didn't find any operations that can generate such stores. As far as I 
>> know, pointers to stack objects cannot be stored in global objects. So is 
>> this a compiler bug? Or the Go compiler does this on purpose to achieve 
>> some optimization I don't know yet?
>>
>> Thanks
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/74ee4bb3-da1b-4db9-a3df-e38d1df28b2dn%40googlegroups.com.

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

[Qingwei Li]

I notice that Go1.17.7 still allocates the array on heap by calling 
newobject while Go1.18 allocates the array on stack. I also notice that in 
the release note of Go1.18 that "The garbage collector now includes 
non-heap sources of garbage collector work". Does the GC in 1.18 and 
following versions of Go ignore some global memory area when marking?

On Thursday, August 3, 2023 at 1:03:31 AM UTC+8 Jinbao Chen wrote:

> I use go1.20.5 to compile the following code. 
> package main
>
> func use(...interface{}) {
>   
> }
>
> func main() {
> testCases := [...][][]int{
> {{42}},
> {{1, 2}},
> {{3, 4, 5}},
> {{}},
> {{1, 2}, {3, 4, 5}, {}, {7}},
> }
> for _, testCase := range testCases {
> use(testCase)
> }
> }
> In the generated SSA and assembly code, I notice that the Go compiler 
> generates some instructions that store a stack pointer(point to the 
> stack-allocated array) into a global slice header.
>
> Just like the assembly code below, the MOV instruction at 0x4585bf stores 
> a stack pointer into a global object: 
>   0x458589 48c7442408   MOVQ $0x0, 0x8(SP) 
>   0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP) 
> testCases := [...][][]int{
>   0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP) 
>   0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP) 
>   0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB) 
>   0x4585b8 750e JNE 0x4585c8 
>   0x4585ba 488d442408 LEAQ 0x8(SP), AX 
>   0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP) 
>   0x4585c6 eb11 JMP 0x4585d9 
>   0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI 
>   0x4585cf 488d442408 LEAQ 0x8(SP), AX 
>   0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB) 
>
> I have read the comments in slicelit 
> ,
>   
> but I didn't find any operations that can generate such stores. As far as I 
> know, pointers to stack objects cannot be stored in global objects. So is 
> this a compiler bug? Or the Go compiler does this on purpose to achieve 
> some optimization I don't know yet?
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/67c81aa6-f6e0-40bf-a74b-273ffc7d02ben%40googlegroups.com.

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

['Keith Randall' via golang-nuts]

Yes, that looks very, very wrong. It looks like this issue goes back to at 
least 1.16.
If you can open an issue at https://github.com/golang/go/issues we can 
investigate.

On Wednesday, August 2, 2023 at 10:03:31 AM UTC-7 Jinbao Chen wrote:

> I use go1.20.5 to compile the following code. 
> package main
>
> func use(...interface{}) {
>   
> }
>
> func main() {
> testCases := [...][][]int{
> {{42}},
> {{1, 2}},
> {{3, 4, 5}},
> {{}},
> {{1, 2}, {3, 4, 5}, {}, {7}},
> }
> for _, testCase := range testCases {
> use(testCase)
> }
> }
> In the generated SSA and assembly code, I notice that the Go compiler 
> generates some instructions that store a stack pointer(point to the 
> stack-allocated array) into a global slice header.
>
> Just like the assembly code below, the MOV instruction at 0x4585bf stores 
> a stack pointer into a global object: 
>   0x458589 48c7442408   MOVQ $0x0, 0x8(SP) 
>   0x458592 48c74424082a00 MOVQ $0x2a, 0x8(SP) 
> testCases := [...][][]int{
>   0x45859b 48c705c28e06000100 MOVQ $0x1, 0x68ec2(IP) 
>   0x4585a6 48c705bf8e06000100 MOVQ $0x1, 0x68ebf(IP) 
>   0x4585b1 833d988d09 CMPL $0x0, runtime.writeBarrier(SB) 
>   0x4585b8 750e JNE 0x4585c8 
>   0x4585ba 488d442408 LEAQ 0x8(SP), AX 
>   0x4585bf 4889059a8e0600 MOVQ AX, 0x68e9a(IP) 
>   0x4585c6 eb11 JMP 0x4585d9 
>   0x4585c8 488d3d918e0600 LEAQ 0x68e91(IP), DI 
>   0x4585cf 488d442408 LEAQ 0x8(SP), AX 
>   0x4585d4 e8e7cf CALL runtime.gcWriteBarrier(SB) 
>
> I have read the comments in slicelit 
> ,
>   
> but I didn't find any operations that can generate such stores. As far as I 
> know, pointers to stack objects cannot be stored in global objects. So is 
> this a compiler bug? Or the Go compiler does this on purpose to achieve 
> some optimization I don't know yet?
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f14aadcd-c0d8-4c61-abca-debe1ab5c208n%40googlegroups.com.

[go-nuts] is this a bug in "go fmt"?

[Sandeep Kalra]

Original code:

$ cat production.go

//go:build production
// +build production
// +build linux  << Notice This Line as my production code is only 
available on Linux

package main

const (
isProductionCode = true
isDebugCode  = false
)

$ go fmt production.go
production.go
$ cat production.go
//go:build production
// +build production

package main

const (
isProductionCode = true
isDebugCode  = false
)
Thanks,
Sandeep Kalra

-- 
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/450aff24-c13d-4a16-a360-93cfeaa21578n%40googlegroups.com.

[go-nuts] Is this a bug ?

[Jamil Djadala]

https://groups.google.com/g/golang-nuts

package main

import (
"fmt"
)

func main() {
const aa int = 0
var a int
fmt.Println(float64(1

[go-nuts] Is there a bug in the command "go list -deps -json ./..."?

[tapi...@gmail.com]

I checked out the kubernetes project at tag v1.20.4.
Then run "go list -deps -json ./... > json,txt" in the project root.
In the produced json.txt file, I notice that the module path for
two packages look not right. The path of a package should be
prefixed with its module path. But the two don't. Bug?

The first:

{
"Dir": 
"/home/lx/mount/sda2/opensource/it-infrastructure/kubernetes/vendor/github.com/Azure/go-autorest/autorest/azure",
"ImportPath": "github.com/Azure/go-autorest/autorest/azure",
"Name": "azure",
"Doc": "Package azure provides Azure-specific implementations used with 
AutoRest.",
"Module": {
"Path": "github.com/Azure/go-autorest/autorest/adal",
"Replace": {
"Path": "github.com/Azure/go-autorest/autorest/adal",
"Version": "v0.9.5"
}
},
...

The second:

{
"Dir": 
"/home/lx/mount/sda2/opensource/it-infrastructure/kubernetes/vendor/cloud.google.com/go/compute/metadata",
"ImportPath": "cloud.google.com/go/compute/metadata",
"Name": "metadata",
"Doc": "Package metadata provides access to Google Compute Engine (GCE) 
metadata and API service accounts.",
"Module": {
"Path": "cloud.google.com/go/bigquery",
"Replace": {
"Path": "cloud.google.com/go/bigquery",
"Version": "v1.4.0"
},
"Indirect": true
},
...

-- 
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/afd7670b-87cf-4ede-9467-648f5d5cbc77n%40googlegroups.com.

Re: [go-nuts] Ambiguous Method Promotion Bug?

['Axel Wagner' via golang-nuts]

"and so does zz.X.Fun", of course.

On Tue, Nov 17, 2020 at 10:14 PM Axel Wagner 
wrote:

> Hi,
>
> the relevant spec section is https://golang.org/ref/spec#Selectors
>
> A selector f may denote a field or method f of a type T, or it may refer
>> to a field or method f of a nested embedded field of T. The number of
>> embedded fields traversed to reach f is called its depth in T. The depth of
>> a field or method f declared in T is zero. The depth of a field or method f
>> declared in an embedded field A in T is the depth of f in A plus one.
>
>
> and
>
> For a value x of type T or *T where T is not a pointer or interface type,
>> x.f denotes the field or method at the shallowest depth in T where there is
>> such an f. If there is not exactly one f with shallowest depth, the
>> selector expression is illegal.
>
>
> In your example, zz.Fun refers to zz.Y.Fun, as that has a depth of 1,
> whereas zz.Q.Fun has a depth of 2 (Q has depth 1 and Fun has depth 1 within
> Q) and zz.X.Fun (X has depth 2 in Z and Fun has depth 0 in X).
>
> Note, in particular, that the check happens at the selector expression,
> not at the type-definition. This is intentional, as it means you can embed
> multiple types without it being an error if they have the same
> fields/methods.
>
> I agree that all of this makes not necessarily for the most readable code,
> but the rule that the shallowest depth must be unique is what makes the
> selector well-defined.
>
> On Tue, Nov 17, 2020 at 9:57 PM Michal Ostrowski 
> wrote:
>
>>
>> Here is a playground doc that demonstrates what seems to be strange
>> behavior regarding promotion of methods.
>>
>> https://play.golang.org/p/R9M1lAOd9CA
>>
>> It seems that I can generate a struct a have an ambiguous method by
>> adding a level of indirection in struct definitions.  Or there's something
>> in the language spec that I'm missing (and I'd appreciate a reference to
>> that in that case.)
>>
>>
>>
>> --
>> 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/cb606644-1b76-4db1-af8c-96b5efac1c20n%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/CAEkBMfFQkMhqdVZL8ydN69uV85uRhRE%2Bs%3DKJ6ECMNSwLoqhgUQ%40mail.gmail.com.

Re: [go-nuts] Ambiguous Method Promotion Bug?

['Axel Wagner' via golang-nuts]

Hi,

the relevant spec section is https://golang.org/ref/spec#Selectors

A selector f may denote a field or method f of a type T, or it may refer to
> a field or method f of a nested embedded field of T. The number of embedded
> fields traversed to reach f is called its depth in T. The depth of a field
> or method f declared in T is zero. The depth of a field or method f
> declared in an embedded field A in T is the depth of f in A plus one.


and

For a value x of type T or *T where T is not a pointer or interface type,
> x.f denotes the field or method at the shallowest depth in T where there is
> such an f. If there is not exactly one f with shallowest depth, the
> selector expression is illegal.


In your example, zz.Fun refers to zz.Y.Fun, as that has a depth of 1,
whereas zz.Q.Fun has a depth of 2 (Q has depth 1 and Fun has depth 1 within
Q) and zz.X.Fun (X has depth 2 in Z and Fun has depth 0 in X).

Note, in particular, that the check happens at the selector expression, not
at the type-definition. This is intentional, as it means you can embed
multiple types without it being an error if they have the same
fields/methods.

I agree that all of this makes not necessarily for the most readable code,
but the rule that the shallowest depth must be unique is what makes the
selector well-defined.

On Tue, Nov 17, 2020 at 9:57 PM Michal Ostrowski  wrote:

>
> Here is a playground doc that demonstrates what seems to be strange
> behavior regarding promotion of methods.
>
> https://play.golang.org/p/R9M1lAOd9CA
>
> It seems that I can generate a struct a have an ambiguous method by adding
> a level of indirection in struct definitions.  Or there's something in the
> language spec that I'm missing (and I'd appreciate a reference to that in
> that case.)
>
>
>
> --
> 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/cb606644-1b76-4db1-af8c-96b5efac1c20n%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/CAEkBMfEkpAKtQo0zUrZ5hwEUa9wEYy%2BX4M_j17mniuap6R-uWw%40mail.gmail.com.

[go-nuts] Ambiguous Method Promotion Bug?

[Michal Ostrowski]

Here is a playground doc that demonstrates what seems to be strange 
behavior regarding promotion of methods.

https://play.golang.org/p/R9M1lAOd9CA

It seems that I can generate a struct a have an ambiguous method by adding 
a level of indirection in struct definitions.  Or there's something in the 
language spec that I'm missing (and I'd appreciate a reference to that in 
that case.)



-- 
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/cb606644-1b76-4db1-af8c-96b5efac1c20n%40googlegroups.com.

Re: [go-nuts] Is this a bug?

[roger peppe]

There's a Go issue which is relevant here:
https://github.com/golang/go/issues/8082


On Sat, 25 May 2019 at 04:54, Dan Kortschak  wrote:

> The interfaces that define the contracts should come from a third
> package/source. The issue that I suspect you are hitting is that type
> identity for interface types is based on the name, not the method set.
> This means that, for example with your code below a function
> PrintB(StringerB) and another function PrintA(StringerA) are not
> assignable to the same variable unless it is type interface{}.
>
> https://play.golang.org/p/a8aWwA6CAB_K // remove comment to see failure
>
> On Fri, 2019-05-24 at 20:38 -0700, Henry wrote:
> > Thanks for the reply.
> >
> > Is there any specific use case that this intended behavior is
> > supposed to
> > solve? It appears to me that it is just a case of simplistic
> > implementation
> > where Go does not look deep enough to see if any dependent interfaces
> > are
> > identical. In this case, Go does not bother to look beyond Formatter
> > interface in order to conclude whether FormatterA and FormatterB are
> > identical. In here, I define 'identical' as being interchangeable,
> > rather
> > than semantic equality. So when I refer to TypeA and TypeB as
> > identical, it
> > means you can use TypeA in place of TypeB, and vice versa.
> >
> > Back to the actual situation, Package A and Package B are developed
> > in
> > tandem by different teams. They have some communication on how their
> > components will interact with each other and fit the bigger picture.
> > They
> > use interface to define contracts that are required in order for
> > their
> > components to work. Since Go interface is implicit, this is supposed
> > to
> > work fine. As an example, if I were to reduce the prior example as
> > follows,
> > it works fine. (Link to the playground:
> > https://play.golang.org/p/zrpjSYTIyxZ)
> >
> > import (
> > "fmt"
> > )
> >
> > func main() {
> > str := MyString("Hello world!")
> > Print(str)
> >
> > strA:=StringerA(str)
> > Print(strA)
> > }
> >
> > type StringerA interface {
> > String() string
> > }
> >
> > type StringerB interface {
> > String() string
> > }
> >
> > type MyString string
> >
> > func (s MyString) String() string {
> > return string(s)
> > }
> >
> > func Print(s StringerB) {
> > fmt.Println(s.String())
> > }
> >
> > However, when I add a more complex interface, as in the first
> > example
> > involving Formatter, it breaks. Go fails to recognize that FormatterA
> > and
> > FormatterB are interchangeable despite the facts that their
> > dependencies
> > (StringerA and StringerB) are interchangeable. Visually, the
> > components
> > should look like this:
> >
> > [image: go.png]
> > Let me know what you think.
> >
> > Thanks.
> >
> > Henry
> >
> > On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
> > >
> > > It's not a bug, FormatterA and FormatterB method has different
> > > signatures, they are not identical, one wants Format(StringerA)
> > > other
> > > Format(StringerB), thus your Format type only implements
> > > FormatterA
> > > but Print wants a FormatterB.
> > >
> >
> >
>
> --
> 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/71965bccd27ed0288b09f9b5b1b3dfc75b3a4ef2.camel%40kortschak.io
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgachMAM1X9yKF5tNoSaNxOnEmWPnGr4Akiq6jp_j%3DZoO4HA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Dan Kortschak]

The interfaces that define the contracts should come from a third
package/source. The issue that I suspect you are hitting is that type
identity for interface types is based on the name, not the method set.
This means that, for example with your code below a function
PrintB(StringerB) and another function PrintA(StringerA) are not
assignable to the same variable unless it is type interface{}.

https://play.golang.org/p/a8aWwA6CAB_K // remove comment to see failure

On Fri, 2019-05-24 at 20:38 -0700, Henry wrote:
> Thanks for the reply. 
> 
> Is there any specific use case that this intended behavior is
> supposed to 
> solve? It appears to me that it is just a case of simplistic
> implementation 
> where Go does not look deep enough to see if any dependent interfaces
> are 
> identical. In this case, Go does not bother to look beyond Formatter 
> interface in order to conclude whether FormatterA and FormatterB are 
> identical. In here, I define 'identical' as being interchangeable,
> rather 
> than semantic equality. So when I refer to TypeA and TypeB as
> identical, it 
> means you can use TypeA in place of TypeB, and vice versa. 
> 
> Back to the actual situation, Package A and Package B are developed
> in 
> tandem by different teams. They have some communication on how their 
> components will interact with each other and fit the bigger picture.
> They 
> use interface to define contracts that are required in order for
> their 
> components to work. Since Go interface is implicit, this is supposed
> to 
> work fine. As an example, if I were to reduce the prior example as
> follows, 
> it works fine. (Link to the playground: 
> https://play.golang.org/p/zrpjSYTIyxZ)
> 
> import (
> "fmt"
> )
> 
> func main() {
> str := MyString("Hello world!")
> Print(str)
> 
> strA:=StringerA(str)
> Print(strA)
> }
> 
> type StringerA interface {
> String() string
> }
> 
> type StringerB interface {
> String() string
> }
> 
> type MyString string
> 
> func (s MyString) String() string {
> return string(s)
> }
> 
> func Print(s StringerB) {
> fmt.Println(s.String())
> }
> 
> However, when I add a more complex interface, as in the first
> example 
> involving Formatter, it breaks. Go fails to recognize that FormatterA
> and 
> FormatterB are interchangeable despite the facts that their
> dependencies 
> (StringerA and StringerB) are interchangeable. Visually, the
> components 
> should look like this:
> 
> [image: go.png]
> Let me know what you think.
> 
> Thanks.
> 
> Henry
> 
> On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
> > 
> > It's not a bug, FormatterA and FormatterB method has different 
> > signatures, they are not identical, one wants Format(StringerA)
> > other 
> > Format(StringerB), thus your Format type only implements
> > FormatterA 
> > but Print wants a FormatterB. 
> > 
> 
> 

-- 
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/71965bccd27ed0288b09f9b5b1b3dfc75b3a4ef2.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Henry]

The posted diagram isn't correct. Updated the diagram with the new one.

[image: go1.png]


On Saturday, May 25, 2019 at 10:38:42 AM UTC+7, Henry wrote:
>
> Thanks for the reply. 
>
> Is there any specific use case that this intended behavior is supposed to 
> solve? It appears to me that it is just a case of simplistic implementation 
> where Go does not look deep enough to see if any dependent interfaces are 
> identical. In this case, Go does not bother to look beyond Formatter 
> interface in order to conclude whether FormatterA and FormatterB are 
> identical. In here, I define 'identical' as being interchangeable, rather 
> than semantic equality. So when I refer to TypeA and TypeB as identical, it 
> means you can use TypeA in place of TypeB, and vice versa. 
>
> Back to the actual situation, Package A and Package B are developed in 
> tandem by different teams. They have some communication on how their 
> components will interact with each other and fit the bigger picture. They 
> use interface to define contracts that are required in order for their 
> components to work. Since Go interface is implicit, this is supposed to 
> work fine. As an example, if I were to reduce the prior example as follows, 
> it works fine. (Link to the playground: 
> https://play.golang.org/p/zrpjSYTIyxZ)
>
> import (
> "fmt"
> )
>
> func main() {
> str := MyString("Hello world!")
> Print(str)
> 
> strA:=StringerA(str)
> Print(strA)
> }
>
> type StringerA interface {
> String() string
> }
>
> type StringerB interface {
> String() string
> }
>
> type MyString string
>
> func (s MyString) String() string {
> return string(s)
> }
>
> func Print(s StringerB) {
> fmt.Println(s.String())
> }
>
> However, when I add a more complex interface, as in the first example 
> involving Formatter, it breaks. Go fails to recognize that FormatterA and 
> FormatterB are interchangeable despite the facts that their dependencies 
> (StringerA and StringerB) are interchangeable. Visually, the components 
> should look like this:
>
> [image: go.png]
> Let me know what you think.
>
> Thanks.
>
> Henry
>
> On Saturday, May 25, 2019 at 1:54:11 AM UTC+7, Wagner Riffel wrote:
>>
>> It's not a bug, FormatterA and FormatterB method has different 
>> signatures, they are not identical, one wants Format(StringerA) other 
>> Format(StringerB), thus your Format type only implements FormatterA 
>> but Print wants a FormatterB. 
>>
>

-- 
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/86e27716-0dbc-42bd-9c81-45243988c3b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Burak Serdar]

On Fri, May 24, 2019 at 10:55 AM Henry  wrote:
>
> Hi,
>
> I stumbled across this weird behavior and I wonder whether this is a bug. 
> Here is the simplified version of the problem (Playground link 
> https://play.golang.org/p/mch6NQdTpr5):

I believe this is working as intended because a type implements an
interface if it has the same method signatures as that interface, and
Format(StringerA) is different from Format(StringerB). However, I
wonder if there is any real reason why this is so because it appears
that the type comparison can be "isCompatible" instead of
"isIdentical" for the argument and return types, and things would
still work.

>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
> str := MyString("World")
> var formatter Format
> Print(formatter, str) //ERROR: have Format(StringerA) string, want 
> Format(StringerB) string
> }
>
> //StringerA and StringerB are identical. Some may wonder why declare 
> identical interfaces in the same package.
> //In a real world example, they live in different packages. StringerA resides 
> in Package A and StringerB is in Package B.
>
> type StringerA interface {
> String() string
> }
>
> type StringerB interface {
> String() string
> }
>
>
> //MyString is the concrete implementation of Stringer. It applies to both 
> StringerA and StringerB.
>
> type MyString string
>
> func (m MyString) String() string {
> return string(m)
> }
>
>
> //Then, we have the Formatter. FormatterA and FormatterB are supposed to be 
> identical. They both accept a Stringer.
> //FormatterA accepts StringerA, because they are in the same package. 
> FormatterB accepts StringerB. Package A and Package B
> //are probably authored by different people and they define their own 
> Stringer. However, since we are dealing with interfaces,
> //so behaviour-wise, they are supposed to be identical. They format a 
> Stringer.
>
> type FormatterA interface {
> Format(StringerA) string
> }
>
> type FormatterB interface {
> Format(StringerB) string
> }
>
>
> //Format is the concrete implementation of Formatter. In this case, Format is 
> implemented by the author of Package A. Let's call him Author A.
> //Hence, we see StringerA there because StringerA is Author A definition of 
> Stringer. However, it is intended to work on any Stringer.
>
> type Format struct{}
>
> func (f Format) Format(s StringerA) string {
> return fmt.Sprintf("Hello %s!", s)
> }
>
>
> //Print is written by Author B. She uses FormatterB and StringerB. Those 
> interfaces are the 'contracts' she requires for her function to work.
> //Her intention is for Print to work with any Formatter and any Stringer. 
> However, Go apparently treat FormatterA and FormatterB as being different.
> //Is this a bug?
>
> func Print(f FormatterB, s StringerB) {
> fmt.Println(f.Format(s))
> }
>
>
> Thanks
>
>
> Henry
>
> --
> 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/e5eb2946-e865-40cd-b1f7-3d445d423e00%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqoW5xBT1vKDdNGWLMitXaMkFUypoNGhcVu0EyLVC4Q6_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Wagner Riffel]

It's not a bug, FormatterA and FormatterB method has different
signatures, they are not identical, one wants Format(StringerA) other
Format(StringerB), thus your Format type only implements FormatterA
but Print wants a FormatterB.

-- 
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/CAFEfeLx%3DLWw5oioneg%3DSFDABJTuM0z4F7fHygh5WFsxHkWgf5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is this a bug?

[Henry]

Hi, 

I stumbled across this weird behavior and I wonder whether this is a bug. 
Here is the simplified version of the problem (Playground link 
https://play.golang.org/p/mch6NQdTpr5):

package main

import (
"fmt"
)

func main() {
str := MyString("World")
var formatter Format
Print(formatter, str) //ERROR: have Format(StringerA) string, want 
Format(StringerB) string
}

//StringerA and StringerB are identical. Some may wonder why declare 
identical interfaces in the same package.
//In a real world example, they live in different packages. StringerA 
resides in Package A and StringerB is in Package B. 

type StringerA interface {
String() string
}

type StringerB interface {
String() string
}


//MyString is the concrete implementation of Stringer. It applies to both 
StringerA and StringerB.

type MyString string

func (m MyString) String() string {
return string(m)
}


//Then, we have the Formatter. FormatterA and FormatterB are supposed to be 
identical. They both accept a Stringer. 
//FormatterA accepts StringerA, because they are in the same package. 
FormatterB accepts StringerB. Package A and Package B
//are probably authored by different people and they define their own 
Stringer. However, since we are dealing with interfaces, 
//so behaviour-wise, they are supposed to be identical. They format a 
Stringer.

type FormatterA interface {
Format(StringerA) string
}

type FormatterB interface {
Format(StringerB) string
}


//Format is the concrete implementation of Formatter. In this case, Format 
is implemented by the author of Package A. Let's call him Author A.
//Hence, we see StringerA there because StringerA is Author A definition of 
Stringer. However, it is intended to work on any Stringer.

type Format struct{}

func (f Format) Format(s StringerA) string {
return fmt.Sprintf("Hello %s!", s)
}


//Print is written by Author B. She uses FormatterB and StringerB. Those 
interfaces are the 'contracts' she requires for her function to work. 
//Her intention is for Print to work with any Formatter and any Stringer. 
However, Go apparently treat FormatterA and FormatterB as being different.
//Is this a bug?

func Print(f FormatterB, s StringerB) {
fmt.Println(f.Format(s))
}


Thanks


Henry

-- 
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/e5eb2946-e865-40cd-b1f7-3d445d423e00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] golang.org/x/oauth2 bug???

[Burak Serdar]

On Fri, Dec 7, 2018 at 6:46 AM Harald Fuchs  wrote:
>
> I think there's something fishy about clientcredentials.  Having
> trouble with client_secrets containig special chars, first I modified
> clientcredentials_test.go like this:
>
> > func TestTokenRequest(t *testing.T) {
> > cfg := newConf("")
> > data := fmt.Sprintf("%s:%s", cfg.ClientID, cfg.ClientSecret)
> > sEnc := base64.StdEncoding.EncodeToString([]byte(data))
> > ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r 
> > *http.Request) {
> > if r.URL.String() != "/token" {
> > t.Errorf("authenticate client request URL = %q; want %q", r.URL, "/token")
> > }
> > headerAuth := r.Header.Get("Authorization")
> > if headerAuth != "Basic "+sEnc {
> > ...
>
> "go test ." succeeded, obviously.
>
> Then I modified the client_secret:
>
> > ClientSecret:   "CLIENT_SECRET=",
>
> Now "go test ." failed!
>
> Changing internal/token.go like this:
>
> > if !bustedAuth {
> > //req.SetBasicAuth(url.QueryEscape(clientID), url.QueryEscape(clientSecret))
> > req.SetBasicAuth(clientID, clientSecret)
> > }

IIRC, Oauth spec requires clientId and clientSecret passed as query
params. There is some code in go oauth implementation to work around
some servers that require clientId/clientSecret in different places,
like Auth header. You are passing the clientId/clientSecret in auth
header, but your servers implementation is not one of the "busted"
ones, so it is expecting to see them in the query, and escaping them
correctly. So you should either send those to in the query, or somehow
convince the library that your test is one of the busted servers.

>
> made "go test ." succeed again.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] golang.org/x/oauth2 bug???

[Harald Fuchs]

I think there's something fishy about clientcredentials.  Having
trouble with client_secrets containig special chars, first I modified
clientcredentials_test.go like this:

> func TestTokenRequest(t *testing.T) {
> cfg := newConf("")
> data := fmt.Sprintf("%s:%s", cfg.ClientID, cfg.ClientSecret)
> sEnc := base64.StdEncoding.EncodeToString([]byte(data))
> ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r 
*http.Request) {
> if r.URL.String() != "/token" {
> t.Errorf("authenticate client request URL = %q; want %q", r.URL, "/token")
> }
> headerAuth := r.Header.Get("Authorization")
> if headerAuth != "Basic "+sEnc {
> ...

"go test ." succeeded, obviously.

Then I modified the client_secret:

> ClientSecret:   "CLIENT_SECRET=",

Now "go test ." failed!

Changing internal/token.go like this:

> if !bustedAuth {
> //req.SetBasicAuth(url.QueryEscape(clientID), 
url.QueryEscape(clientSecret))
> req.SetBasicAuth(clientID, clientSecret)
> }

made "go test ." succeed again.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] gob limitation or bug?

[Hoping White]

package main

import (
   "bytes"
   "encoding/gob"
   "fmt"
)

var data = bytes.NewBuffer(nil)
var buff = bytes.NewBuffer(nil)
var encoder = gob.NewEncoder(data)
var decoder = gob.NewDecoder(buff)

func main() {
   encode()
   decode()
   decode()
}

func encode() {
   n := [][]int32{[]int32{1}, []int32{2, 3}, []int32{4, 5, 6}}
   encoder.Encode()
   fmt.Printf("encode bytes:%v len:%d\n", data.Bytes(), data.Len())
}

func decode() {
   buff.Write(data.Bytes())
   println("data size", buff.Len(), data.Len())
   var n [][]int32
   err := decoder.Decode()
   if err != nil {
  println("decode err:", err.Error())
   }
   println("data left:", buff.Len())
   fmt.Printf("%v\n", n)
}

Run output:

encode bytes:[13 255 131 2 1 2 255 132 0 1 255 130 0 0 12 255 129 2 1
2 255 130 0 1 4 0 0 13 255 132 0 3 1 2 2 4 6 3 8 10 12] len:41data
size 41 41
data left: 0[[1] [2 3] [4 5 6]]data size 41 41
decode err: extra data in buffer
data left: 27[]


I found that, encode a slice would failed, but a struct ok. Is this a bug
or limitation of gob?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] 【go-nuts] liteide x35.2 released, bug fixed.

[visualfc]

Hi, all.
LiteIDE X35.2 released!
This version fixed jump source bug. Optimization editor/bookmark/golangdoc 
plugins.

* LiteIDE Home
       
* LiteIDE Source code
       
* Release downloads
       
       
    
### 2018.11.12 Ver X35.2
* LiteIDE
       fixed types info jump position
       optimization types info lookup cache
* LiteEditor
       single line comment set after white spaces and add space
       go.mod editor support comment action
       color scheme support MatchBrackets background, default gray #808080
* Bookmarks
       sort bookmark model by name/line, add context menu 
goto/remove/removeThisFile/removeAllFiles action
* GolangDoc
       fix mod package godoc import path view
* GolangEdit
       fix lookup types info by gocode cache
* gotools & gocode
       fixed types jump info position
       optimization types info lookup cache

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[T L]

On Saturday, March 17, 2018 at 1:54:17 AM UTC-4, T L wrote:
>
>
>
> On Friday, March 16, 2018 at 3:31:23 PM UTC-4, Axel Wagner wrote:
>>
>>
>>
>> On Fri, Mar 16, 2018 at 8:20 PM, T L  wrote:
>>
>>>
>>>
>>> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:

 On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:


 > I feel the second append call should be also valid.

 Works as intended: T is not struct{}

 If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw


 -- 

 -j

>>>
>>> yes, alias works.
>>>
>>> Just realize that this is not a "append" specified question.
>>> I feel the following one should be also valid.
>>>
>>
>> This is the same question of why you can't convert `[]int` to 
>> `[]interface{}` - it's a costly operation and Go tends to not hide 
>> expensive operations from you.
>>
>
> Yes. But I think there is a little specialty here.
> It is a problem of which viewpoint is right.
> 1. fmt.Println(1, 2, 3) is a shorthand of fmt.Println([]interface{1, 2, 
> 3}...)
> 2. fmt.Println(aBlankInterfaceSlice...) is a shorthand of 
> fmt.Println(aBlankInterfaceSlice[0], aBlankInterfaceSlice[1], ..., 
> aBlankInterfaceSlice[N])
>

Go spec does imply the first viewpoint is right.
 

>  
>
>>  
>>
>>>
>>> package main
>>>
>>> import "fmt"
>>>
>>> func main() {
>>> s := []int{1, 2, 3}
>>> fmt.Println(s...)
>>> }
>>>
>>>  
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[T L]

On Friday, March 16, 2018 at 3:31:23 PM UTC-4, Axel Wagner wrote:
>
>
>
> On Fri, Mar 16, 2018 at 8:20 PM, T L  
> wrote:
>
>>
>>
>> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:
>>>
>>> On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:
>>>
>>>
>>> > I feel the second append call should be also valid.
>>>
>>> Works as intended: T is not struct{}
>>>
>>> If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw
>>>
>>>
>>> -- 
>>>
>>> -j
>>>
>>
>> yes, alias works.
>>
>> Just realize that this is not a "append" specified question.
>> I feel the following one should be also valid.
>>
>
> This is the same question of why you can't convert `[]int` to 
> `[]interface{}` - it's a costly operation and Go tends to not hide 
> expensive operations from you.
>

Yes. But I think there is a little specialty here.
It is a problem of which viewpoint is right.
1. fmt.Println(1, 2, 3) is a shorthand of fmt.Println([]interface{1, 2, 
3}...)
2. fmt.Println(aBlankInterfaceSlice...) is a shorthand of 
fmt.Println(aBlankInterfaceSlice[0], aBlankInterfaceSlice[1], ..., 
aBlankInterfaceSlice[N])
 

>  
>
>>
>> package main
>>
>> import "fmt"
>>
>> func main() {
>> s := []int{1, 2, 3}
>> fmt.Println(s...)
>> }
>>
>>  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

['Axel Wagner' via golang-nuts]

On Fri, Mar 16, 2018 at 8:20 PM, T L  wrote:

>
>
> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:
>>
>> On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:
>>
>>
>> > I feel the second append call should be also valid.
>>
>> Works as intended: T is not struct{}
>>
>> If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw
>>
>>
>> --
>>
>> -j
>>
>
> yes, alias works.
>
> Just realize that this is not a "append" specified question.
> I feel the following one should be also valid.
>

This is the same question of why you can't convert `[]int` to
`[]interface{}` - it's a costly operation and Go tends to not hide
expensive operations from you.


>
> package main
>
> import "fmt"
>
> func main() {
> s := []int{1, 2, 3}
> fmt.Println(s...)
> }
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[T L]

On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:
>
> On Fri, Mar 16, 2018 at 7:40 PM T L  
> wrote:
>
>
> > I feel the second append call should be also valid.
>
> Works as intended: T is not struct{}
>
> If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw
>
>
> -- 
>
> -j
>

yes, alias works.

Just realize that this is not a "append" specified question.
I feel the following one should be also valid.

package main

import "fmt"

func main() {
s := []int{1, 2, 3}
fmt.Println(s...)
}

 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] an "append" use, bug or intended design?

[Jan Mercl]

On Fri, Mar 16, 2018 at 7:40 PM T L  wrote:


> I feel the second append call should be also valid.

Works as intended: T is not struct{}

If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw


-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] an "append" use, bug or intended design?

[T L]

package main

import "fmt"

type T struct{}

func main() {
s := []struct{}{
struct{}{},
}
var x []T
x = append(x, s[0]) // valid
x = append(x, s...) // invalid
fmt.Println(x)
}

I feel the second append call should be also valid.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Marvin Renich]

The point to remember is that each value of a concrete type has exactly
that one concrete type, while each value of an interface type has
exactly one interface type and one concrete type.

It is also important to note that there is a distinction between
"assignability" and "type-assertiblity".

* Bakul Shah  [180225 03:48]:
> https://play.golang.org/p/IMWd3cvgfsU
> 
> // also replicated below
> 
> package main
> 
> import (
>   "fmt"
> )
> 
> type (
>   T1 interface{ f1()int; f2()int }
>   T2 interface{ f2()int; f3()int }
> )
> type C int
> func (c C)f1()int {return 1}
> func (c C)f2()int {return 2}
> func (c C)f3()int {return 3}
> 
> func main() {
>   var (x1 T1; x2 T2; c C; o interface{})
>   fmt.Printf("%T, %T, %T, %T\n", x1, x2, o, c)
>   p(x1);p(x2);p(o);p(c)
>
>   x1 = c; x2 = c; o = c
>   fmt.Printf("%T, %T, %T, %T\n", x1, x2, o, c)
>   p(x1);p(x2);p(o);p(c)
^

x2 (type T2) is assignable to the argument of p (type interface{}), but
when the assignment happens, the value loses the information that it
came from a value with interface type T2.  The o argument to p has
interface type interface{} and concrete type C, even though it came from
a value with interface type T2.

> }
>   
> func p(o interface{}) {
>   switch o.(type) {

A type switch uses the first case that can match (i.e.
type-assertibility, not assignability).  For the x2 case above, o still
only has interface type interface{} and concrete type C.  However C is
type-assertible to type T1, so the first case matches (and so do all the
others, except default, but the first matching case wins).

>   case T1: fmt.Println("T1")
>   case T2: fmt.Println("T2")
>   case C: fmt.Println("C")
>   case interface{}: fmt.Println("interface{}")
>   default: fmt.Println("?")
>   }
> }

It is also worth emphasizing that if you changed the argument to p from
interface{} to T2, the following snippet would still print "T1":

func main() {
var x2 T2
var c C
x2 = c
p(x2)
}

func p(o T2) {
// remainder of function as above
...
}

...Marvin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Bakul Shah]

On Sun, 25 Feb 2018 09:25:42 + Jan Mercl <0xj...@gmail.com> wrote:
Jan Mercl writes:
> --f4f5e808e63ceebaa7056605faf5
> Content-Type: text/plain; charset="UTF-8"
> 
> On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah  wrote:
> 
> > Why not case T2?
> 
> It does match T2 as well. The order of cases of the type switch maters:
> https://play.golang.org/p/nb28xHQP7oU

Duh! Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Jan Mercl]

On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah  wrote:

> Why not case T2?

It does match T2 as well. The order of cases of the type switch maters:
https://play.golang.org/p/nb28xHQP7oU

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug?

[Bakul Shah]

On Sun, 25 Feb 2018 01:01:08 -0800 Dave Cheney  wrote:
Dave Cheney writes:
> --=_Part_12529_340231507.1519549268925
> Content-Type: text/plain; charset="UTF-8"
> 
> Type C conforms to the T1 interface?
> 
> What did you expect?

C conforms to both T1 and T2.

var x2 T2
x2 = c 

switch x2.(type) matches case T1 -- this is what I find
strange. Why not case T2?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is this a bug?

[Dave Cheney]

Type C conforms to the T1 interface?

What did you expect?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is this a bug?

[Bakul Shah]

https://play.golang.org/p/IMWd3cvgfsU

// also replicated below

package main

import (
"fmt"
)

type (
T1 interface{ f1()int; f2()int }
T2 interface{ f2()int; f3()int }
)
type C int
func (c C)f1()int {return 1}
func (c C)f2()int {return 2}
func (c C)f3()int {return 3}

func main() {
var (x1 T1; x2 T2; c C; o interface{})
fmt.Printf("%T, %T, %T, %T\n", x1, x2, o, c)
p(x1);p(x2);p(o);p(c)

x1 = c; x2 = c; o = c
fmt.Printf("%T, %T, %T, %T\n", x1, x2, o, c)
p(x1);p(x2);p(o);p(c)

}

func p(o interface{}) {
switch o.(type) {
case T1: fmt.Println("T1")
case T2: fmt.Println("T2")
case C: fmt.Println("C")
case interface{}: fmt.Println("interface{}")
default: fmt.Println("?")
}
}

The output is

, , , main.C
?
?
?
T1  <<==
main.C, main.C, main.C, main.C
T1
T1  <<==
T1  <<==
T1  <<==

In particular I don't undertand the lines marked with <<==.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Float multiplication bug?

[Michael Jones]

This question is already answered, but i was on a plane and added a bit to
the printing and the comments. in case anyone ever refers to this thread in
the future, this is the better version of the program to run:
https://play.golang.org/p/EK0XMnMUKwv

On Fri, Feb 23, 2018 at 8:06 AM, Michael Jones 
wrote:

> One subtle thing is the difference between an ideal number, its
> floating-point representation, and its printed form.
>
> On Fri, Feb 23, 2018 at 5:46 AM,  wrote:
>
>> Thanks guys. That's very helpful.  I forgot that what I saw (and re-used)
>> as the "height" was not precise enough to make it comparable.
>>
>>
>> On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>>>
>>>
>>>  Hello Everyone,
>>>
>>>  This looks like a Golang bug to me. What do you all think?
>>>
  I have this function ...
>>>
>>> func getArea(base, side int64) float64 {
 var height, fSide, area float64
 fSide = float64(side)
 halfBase := float64(base) / 2.0
 height = math.Sqrt(fSide*fSide - halfBase*halfBase)
 area = halfBase * height
 fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
 area)

>>>
>>>
 hb2 := 151414.5
 h2 := 262256.452301
 fmt.Printf("Area 2: %f\n", hb2 * h2)

>>>
>>>
 return area
 }
>>>
>>>
>>> When I call it with `result := getArea(302829, 302828)`,   I get this
>>> output ...
>>>
>>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
 Area 2: 39709429596.929764
>>>
>>>
>>> I could see how some kind of rounding could produce the first Area
>>> value.  But in that case, why wouldn't Area2 be rounded as well?
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>



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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Float multiplication bug?

[Michael Jones]

One subtle thing is the difference between an ideal number, its
floating-point representation, and its printed form.

On Fri, Feb 23, 2018 at 5:46 AM,  wrote:

> Thanks guys. That's very helpful.  I forgot that what I saw (and re-used)
> as the "height" was not precise enough to make it comparable.
>
>
> On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>>
>>
>>  Hello Everyone,
>>
>>  This looks like a Golang bug to me. What do you all think?
>>
>>>  I have this function ...
>>
>> func getArea(base, side int64) float64 {
>>> var height, fSide, area float64
>>> fSide = float64(side)
>>> halfBase := float64(base) / 2.0
>>> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>>> area = halfBase * height
>>> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
>>> area)
>>>
>>
>>
>>> hb2 := 151414.5
>>> h2 := 262256.452301
>>> fmt.Printf("Area 2: %f\n", hb2 * h2)
>>>
>>
>>
>>> return area
>>> }
>>
>>
>> When I call it with `result := getArea(302829, 302828)`,   I get this
>> output ...
>>
>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
>>> Area 2: 39709429596.929764
>>
>>
>> I could see how some kind of rounding could produce the first Area
>> value.  But in that case, why wouldn't Area2 be rounded as well?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Float multiplication bug?

[steve_bagwell]

Thanks guys. That's very helpful.  I forgot that what I saw (and re-used) 
as the "height" was not precise enough to make it comparable.

On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote:
>
>
>  Hello Everyone,
>
>  This looks like a Golang bug to me. What do you all think?
>
>>  I have this function ...
>
> func getArea(base, side int64) float64 {
>> var height, fSide, area float64
>> fSide = float64(side)
>> halfBase := float64(base) / 2.0
>> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>> area = halfBase * height
>> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height, area)
>>
>  
>
>> hb2 := 151414.5
>> h2 := 262256.452301
>> fmt.Printf("Area 2: %f\n", hb2 * h2)
>>
>  
>
>> return area
>> }
>
>  
> When I call it with `result := getArea(302829, 302828)`,   I get this 
> output ...
>
> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
>> Area 2: 39709429596.929764
>
>
> I could see how some kind of rounding could produce the first Area value.  
> But in that case, why wouldn't Area2 be rounded as well?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Tamás Gulácsi]

When you append to a slice with the append function, it just assigns the value 
to the len.th slot and increments len.
This is only possible, if the backing array is big enough. This backing array 
capacity is the slice's capacity, retrieved by cap.

If the capacity is not enough, a new, bigger backing array is allocated, 
everything is copied to it, plus the new element.

This allocation and copy costs cpu cycles and garbage collection time, so each 
time the backing array is doubled till 1024, then *1.25, but this is 
deterministic.

So if your program is deterministic, the backing array will have the capacity  
to hold the values for multiple cycles in a specific point in your program.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Sasan Rose]

Hi Jesse

Thank you very much. I guess that happens when you come to Go with a PHP 
background. I still have one question, why does it happen always on that 
iteration? Not the previous iterations?

On Tuesday, December 19, 2017 at 4:32:09 PM UTC+11, Jesse McNelis wrote:
>
> On Tue, Dec 19, 2017 at 4:10 PM, Sasan Rose  > wrote: 
> > Hi Jess 
> > 
> > Apologies for my bad example. Please kindly see my reply to Dave's post. 
> > Thanks 
>
> I fixed your example so that the slice called 'combination' isn't 
> shared with every slice in every iteration of the loop. 
> https://play.golang.org/p/s0WvBuZr_P 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Jesse McNelis]

On Tue, Dec 19, 2017 at 4:10 PM, Sasan Rose  wrote:
> Hi Jess
>
> Apologies for my bad example. Please kindly see my reply to Dave's post.
> Thanks

I fixed your example so that the slice called 'combination' isn't
shared with every slice in every iteration of the loop.
https://play.golang.org/p/s0WvBuZr_P

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Sasan Rose]

Hi Jess

Apologies for my bad example. Please kindly see my reply to Dave's post. 
Thanks

On Tuesday, December 19, 2017 at 2:43:50 PM UTC+11, Jesse McNelis wrote:
>
> On Tue, Dec 19, 2017 at 8:54 AM, Sasan Rose  > wrote: 
> > Please take a look at https://play.golang.org/p/BL4LUGk-lH 
>
> solutionNew = make([]int, 0) 
> solutionNew = append(solution, 2) 
>
> Is a strange thing to do, you create a new slice using make([]int, 0) 
> and then never use it. 
> perhaps you wanted to use copy()? 
>
>
> The problem you're encountering is slices can share backing arrays. 
> Each time you append to the slice called 'solution', you're modifying 
> the same backing array. 
>
> In your code: 
>
> /*You append 2 to solution creating a slice that points to the same 
> memory as 'solution'*/ 
>  solutionNew = append(solution, 2) 
>
> /* You append this slice to a slice called slice */ 
>  slice = append(slice, solutionNew) 
>
> /* You append a 4 to the same slice called 'solution' which shares 
> memory with slice you appended to your slice called 'slice' thus you 
> override the 2 you append to 'solution' with a 4*/ 
>  solutionNew = append(solution, 4) 
>
> /* You append the slice to 'slice' so now there are two slices in 
> 'slice' that refer to the same memory and thus have the same value */ 
>  slice = append(slice, solutionNew) 
>
>
> - Jesse 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is this a bug or am I missing something?

[Jesse McNelis]

On Tue, Dec 19, 2017 at 8:54 AM, Sasan Rose  wrote:
> Please take a look at https://play.golang.org/p/BL4LUGk-lH

solutionNew = make([]int, 0)
solutionNew = append(solution, 2)

Is a strange thing to do, you create a new slice using make([]int, 0)
and then never use it.
perhaps you wanted to use copy()?


The problem you're encountering is slices can share backing arrays.
Each time you append to the slice called 'solution', you're modifying
the same backing array.

In your code:

/*You append 2 to solution creating a slice that points to the same
memory as 'solution'*/
 solutionNew = append(solution, 2)

/* You append this slice to a slice called slice */
 slice = append(slice, solutionNew)

/* You append a 4 to the same slice called 'solution' which shares
memory with slice you appended to your slice called 'slice' thus you
override the 2 you append to 'solution' with a 4*/
 solutionNew = append(solution, 4)

/* You append the slice to 'slice' so now there are two slices in
'slice' that refer to the same memory and thus have the same value */
 slice = append(slice, solutionNew)


- Jesse

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is this a bug or am I missing something?

[Sasan Rose]

Please take a look at https://play.golang.org/p/BL4LUGk-lH

I think I know how slices work (The 3-word structure). I tried to do my 
homework. But still I think I'm missing something here or it's really a bug.

So In my code as you can see I'm appending to an slice (a variable called 
slice obviously) and removing from the beginning of it in a series of 
random operations (Actually it's not random it was happening in a loop but 
I tried to reproduce it this way). The problem is always at the last step 
(I separated each step by "=" signs) when I append to the array the (n-1)th 
element of array also changes to the appended value (This only happens when 
I create the appended value by appending an int to 'solutionNew' variable).

Am I doing something wrong? Is this an intended behaviour? or is this 
really a bug? If I'm missing something I would be grateful if someone could 
explain it to me or share a reference with me so I can understand why this 
is happening. Thanks 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] go test/flag.NewFlagSet bug?

[gocss]

when I run the minimal program below it errors about NOT knowing  -data 
flag:
go test -v -args -data=x
flag provided but not defined: -data
Usage of 
/tmp/go-build454762170/github.com/phcurtis/flagexp/_test/flagexp.test:
  -test.bench regexp  blah blah,

if you change nfs=false ... and then it uses flag.Parse etc ... code runs 
without issue
but I want to handle error cases in other code I'm working and use  the 
flag.NewFlagSet with go test ...
note the below code in either case works with go run but not with go test.


package main

import (
"flag"
"fmt"
"os"
"testing"
)

var data string
var test func(t *testing.T)
var datainit = "defValue"
var nfs = true

func init() {
if nfs {
flag3 := flag.NewFlagSet("nfs", flag.ContinueOnError)
flag3.StringVar(, "data", datainit, "data")
test = func(t *testing.T) {
fmt.Println("TP1")
err := flag3.Parse(os.Args)
fmt.Printf("data:%v err:%v\n", data, err)
}
return
}
flag.StringVar(, "data", datainit, "data")
test = func(t *testing.T) {
fmt.Println("TP2")
flag.Parse()
fmt.Printf("data:%v\n", data)
}
}

func Test_code(t *testing.T) {
test(t)
}

***
heres full output when nfs=true
paul@t560:~/go/src/github.com/phcurtis/flagexp$ go test -v -args -data=x
flag provided but not defined: -data
Usage of 
/tmp/go-build454762170/github.com/phcurtis/flagexp/_test/flagexp.test:
  -test.bench regexp
run only benchmarks matching regexp
  -test.benchmem
print memory allocations for benchmarks
  -test.benchtime d
run each benchmark for duration d (default 1s)
  -test.blockprofile file
write a goroutine blocking profile to file
  -test.blockprofilerate rate
set blocking profile rate (see runtime.SetBlockProfileRate) 
(default 1)
  -test.count n
run tests and benchmarks n times (default 1)
  -test.coverprofile file
write a coverage profile to file
  -test.cpu list
comma-separated list of cpu counts to run each test with
  -test.cpuprofile file
write a cpu profile to file
  -test.list regexp
list tests, examples, and benchmarch maching regexp then exit
  -test.memprofile file
write a memory profile to file
  -test.memprofilerate rate
set memory profiling rate (see runtime.MemProfileRate)
  -test.mutexprofile string
write a mutex contention profile to the named file after execution
  -test.mutexprofilefraction int
if >= 0, calls runtime.SetMutexProfileFraction() (default 1)
  -test.outputdir dir
write profiles to dir
  -test.parallel n
run at most n tests in parallel (default 4)
  -test.run regexp
run only tests and examples matching regexp
  -test.short
run smaller test suite to save time
  -test.timeout d
panic test binary after duration d (0 means unlimited)
  -test.trace file
write an execution trace to file
  -test.v
verbose: print additional output
exit status 2
FAILgithub.com/phcurtis/flagexp0.001s

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Possible optimization bug in go1.8?

[Volker Dobler]

On Monday, 8 May 2017 15:51:00 UTC+2, Shabinesh Sivaraj wrote:
>
> func xrand() int {
> r := rand.New(rand.NewSource(99))
> return r.Int()
> } 
>
What am I missing here?  Could it be a bug?
>

Not a bug.
 r := rand.New(rand.NewSource(99))
creates a new random number generator seeded to a constant
value of 99 (roughly) and
r.Int()
reads one single number from this r. As r is _pseudo_ random
and has a constant state (seeded to 99) you always get the
same number.

V.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is there a bug in path.Dir?

[18126523585]

In windows platform, path.Dir and path.Base can't get the correct result. 

The test code is like this:

func main() {
   filename := "F:\\Test\\conf\\rkc1"
   i := strings.LastIndex(filename, string(filepath.Separator))
   fmt.Println("dir1:", string(filename[:i+1]))
   fmt.Println("base1:", string(filename[i+1:]))

   fmt.Println("dir2:", path.Dir(filename))
   fmt.Println("base2:", path.Base(filename))
}



result is :
dir1: F:\Test\conf\
base1: rkc1
dir2: .
base2: F:\Test\conf\rkc1


The dir2 and base2 is not correct , look into the path.Dir, the code is 
hard code with "/", but not filepath.Separator. 

Can it be considered as a bug in golang lib?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.