profile
viewpoint
Ian Lance Taylor ianlancetaylor @google Berkeley, California, USA http://www.airs.com/ian/

avelino/awesome-go 52259

A curated list of awesome Go frameworks, libraries and software

ianlancetaylor/libbacktrace 261

A C library that may be linked into a C/C++ program to produce symbolic backtraces

ianlancetaylor/demangle 61

C++ symbol name demangler written in Go

ianlancetaylor/cgosymbolizer 38

Experimental symbolizer for cgo backtraces

carlosedp/riscv-bringup 34

Risc-V journey thru containers and new projects

4ad/go.arm64 18

Go development tree for the arm64 port (historical).

thanm/dragongo 15

LLVM IR generation "middle end" for LLVM-based go compiler.

ianlancetaylor/compress 1

Optimized compression packages

ianlancetaylor/rkt 1

rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.

ianlancetaylor/git2go 0

Git to Go. Like McDonald's but tastier.

issue commentgolang/go

time: racy Timer access should either work or throw, not panic

@gopherbot Please open a backport to 1.14.

bcmills

comment created time in 7 hours

issue commentgolang/go

proposal: Go 2 error values

@changkun We are unlikely to do anything about error handling any time soon. But this proposal is not about error handling. It is about error values. They are different things. See, e.g., the separate discussions of error values and error handling at https://go.googlesource.com/proposal/+/master/design/go2draft.md.

jba

comment created time in 9 hours

issue commentgolang/go

x/lint: recommend parameters in func type signatures

See the comments at the top of https://golang.org/wiki/CodeReviewComments.

l0k18

comment created time in 9 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Ah, sorry, missed that. So according to that comment on some systems the release field and the version field returned by uname differ at to the kernel version that they report. We currently check the release field but not the version field.

The /proc/version file has a different set of information again.

My Ubuntu system has /proc/version but does not have /proc/version_signature.

karalabe

comment created time in 14 hours

issue commentgolang/go

x/lint: recommend parameters in func type signatures

Yes. But it remains the case that we don't expect the linter to fire on ordinary code.

Also, again, see the Scope section of https://go.googlesource.com/lint/+/refs/heads/master/README.md. That describes the kind of changes we expect to implement in x/lint.

l0k18

comment created time in 14 hours

issue commentgolang/go

cmd/cgo: -godefs: incorrect output when using TAILQ_ENTRY

The -godefs option is not actually supported for anything other than its documented purpose of generating files in the syscall package. I don't mind if somebody sends in a fix for this, but this is not a priority of the Go team. Sorry.

I'll add that I'm honestly not sure how -godefs is expected to work in the presence of a combination of typedefs and direct struct references.

yoursunny

comment created time in 14 hours

issue commentgolang/go

cmd/cgo: -godefs: incorrect output when using TAILQ_ENTRY

This is caused by https://golang.org/cl/181857 for issue #31891.

CC @letientai299

yoursunny

comment created time in 14 hours

issue commentgolang/go

cmd/cgo: -godefs: incorrect output when using TAILQ_ENTRY

Standalone test case:

package demo

/*
typedef struct A A;

typedef struct {
	struct A *next;
	struct A **prev;
} N;

struct A
{
  N n;
};

typedef struct B
{
  A* a;
} B;
*/
import "C"

type N C.N

type A C.A

type B C.B
yoursunny

comment created time in 14 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Thanks, we already check that in the uname results.

karalabe

comment created time in 14 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

@jrockway Thanks, the problem is not that we don't have the kernel version, it's that Ubuntu is using a kernel version that has the bug, but Ubuntu has applied a patch for the bug, so the kernel actually works, but we don't know how to detect that fact.

karalabe

comment created time in 16 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Here is something we could do:

  1. Use uname to check the kernel version for a vulnerable kernel, as we do today.
  2. If the kernel is vulnerable according to the version, read /proc/version.
  3. If /proc/version contains the string "2020", assume that the kernel is patched.
  4. If /proc/version contains the string "gcc version 8" assume that the kernel works even if patched (as the bug only occurs when the kernel is compiled with GCC 9 or later).
  5. Otherwise, call mlock on signal stacks as we do today on vulnerable kernels.

The point of this is to reduce the number of times that Go programs run out of mlock space.

Does anybody know of any unpatched kernels that may have the string "2020" in /proc/version?

For safety we should probably try to identify the times when the kernel was patched for the major distros. Is there anybody who can identify that for any particular distro? Thanks. The thinking here

karalabe

comment created time in 17 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Go programs will only report the error message on kernels with a version number that indicates that they may have the problem.

karalabe

comment created time in 17 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

@ucirello There is no problem on 4.4.x Linux kernels. The bug first appeared in kernel version 5.2.

karalabe

comment created time in 17 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Perhaps we could use the date recorded in /proc/version as an additional signal. It should probably be release specific, which is a pain. But the whole thing is painful.

karalabe

comment created time in 18 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

@ucirello Are you seeing any problem running Go programs on the system that you describe?

karalabe

comment created time in 19 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

What are the contents of /proc/version for an example kernel that is patched to work correctly but for which Go is currently producing the mlock error? Thanks.

karalabe

comment created time in 19 hours

issue closedgolang/go

how to close tcp keep-alive for http.ListenAndServer

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.14 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="on" GOARCH="amd64" GOBIN="/Users/xx/Documents/develop/go/workspace/bin" GOCACHE="/Users/xx/Library/Caches/go-build" GOENV="/Users/xx/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/xx/Documents/develop/go/workspace" GOPRIVATE="" GOPROXY="direct" GOROOT="/usr/local/go" GOSUMDB="off" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/dev/null" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7r/fpcvbc6d32j2lfls0lllcs240000gn/T/go-build785679791=/tmp/go-build -gno-record-gcc-switches -fno-common" GOROOT/bin/go version: go version go1.14 darwin/amd64 GOROOT/bin/go tool compile -V: compile version go1.14 uname -v: Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.15.3 BuildVersion: 19D76 lldb --version: lldb-1100.0.30.12 Apple Swift version 5.1.3 (swiftlang-1100.0.282.1 clang-1100.0.33.15) </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

edit main.go

`package main

import ( "log" "net/http" )

func main() { addr := "127.0.0.1:8080" http.HandleFunc("/agent", agentHandler)

srv := http.Server{
	Addr: addr,
}
srv.SetKeepAlivesEnabled(false)

err := srv.ListenAndServe()
log.Fatal(err)

}

func agentHandler(w http.ResponseWriter, r *http.Request) { } `

in terminal1 go run main.go

in terminal2 telnet 127.0.0.1 8080

What did you expect to see?

http server not actively send a tcp keep-alive to client or i can change time of send tcp keep-alive

What did you see instead?

every 15s, http server actively send a tcp keep-alive to client

image

closed time in 21 hours

orange-jacky

issue commentgolang/go

how to close tcp keep-alive for http.ListenAndServer

We generally do not use the issue tracker for questions. You will get better and faster answers on a forum. See https://golang.org/wiki/Questions. Thanks.

The srv.SetKeepAlivesEnabled method applies to HTTP keep-alives. What you are seeing is a different thing: TCP keep-alives. TCP keep-alives are controlled by methods like https://golang.org/pkg/net/#TCPConn.SetKeepAlive. I'm not sure but I think you could probably set this by using ConnState in your http.Server. Asking on a forum may get better advice.

orange-jacky

comment created time in 21 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Actually, could the runtime fork a child process on startup (for 5.3.x & 5.4.x) that triggers the bug and enable the workaround if it does? IIRC there is a reliable reproducer, see #35326 (comment)

It's an interesting idea but I think that in this case the test is much too expensive to run at startup for every single Go program.

karalabe

comment created time in 21 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Disabling async preemption is a distraction. Programs running on faulty kernels are still broken. It's just that the brokenness shows up as weird memory corruption rather than as an error about running into an mlock limit that points to kernel versions. While obviously we want to fix the problem entirely, I think that given the choice of a clear error or random memory corruption we should always pick the clear error.

I agree that kernel version detection is terrible, it's just that we don't know of any other option. If anybody has any suggestions in that regard, that would be very helpful.

One thing that we could do is add a GODEBUG setting to disable mlocking the signal stack. That would give people a workaround that is focused on the actual problem. We can mention that setting in the error message. I'm afraid that it will lead to people to turn on the setting whether they have a patched kernel or not. But at least it will give people who really do have a patched kernel a way to work around this problem. CC @aclements

karalabe

comment created time in 21 hours

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

I personally am not convinced by "let's do this now and figure out how to do more later." Sometimes that is the right approach, but sometimes it's important to at least understand how we could do more later.

Right now people are confused because when they panic in a test deferred functions in TestMain are not run. If we fix that, people will be confused because when they panic in a goroutine started by a test deferred functions in TestMain are not run. Although the current state is not good, at least it's consistent.

orlangure

comment created time in a day

issue commentgolang/go

runtime: mlock of signal stack failed: 12

@networkimprov Disabling signal preemption makes the bug less likely to occur but it is still present. It's a bug in certain Linux kernel versions. The bug affects all programs in all languages. It's particularly likely to be observable with Go programs that use signal preemption, but it's present for all other programs as well.

Go tries to work around the bug by mlocking the signal stack. That works fine unless you run into the mlock limit. I suppose that one downside of this workaround is that we make the problem very visible, rather than occasionally failing due to random memory corruption as would happen if we didn't do the mlock.

At some point there is no way to work around a kernel bug.

karalabe

comment created time in a day

issue closedgolang/go

Os.Stat() File permissions representation

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.13.5 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GO111MODULE="" GOARCH="amd64" GOBIN="/home/luke/go/bin" GOCACHE="/home/luke/.cache/go-build" GOENV="/home/luke/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/luke/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/lib/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/luke/go/src/gosec/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build651612000=/tmp/go-build -gno-record-gcc-switches" <details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

I need to use golang to get the file permissions of a given file (specifically the SUID bit). Here are the permissions of an example file.

$ touch example_file.test
$ chmod 7777 example_file.test
$ ls -ltra example_file.test
	-rwsrwsrwt 1 luke users 0 Feb 25 21:53 example_file.test
	
$ stat -c "%a %n" example_file.test
     7777 example_file.test

Here is a tiny program illustrating the issue.

func main() {
	info, _ := os.Stat("example_file.test")
        fmt.Println(info.Mode().String())			             // ugtrwxrwxrwx
        fmt.Println(info.Mode().Perm().String())		         // -rwxrwxrwx
        fmt.Printf("permissions: %#o\n", info.Mode().Perm())     // permissions: 0777
}

The golang results are inconsistant because ugtrwxrwxrwx != 0777.

The following quote from the documentation indicates that this might be a cross-platform compatibility issue.

A FileMode represents a file's mode and permission bits. The bits have the same definition on all systems, so that information about files can be moved from one system to another portably. Not all bits apply to all systems. The only required bit is ModeDir for directories.

type FileMode uint32 The defined file mode bits are the most significant bits of the FileMode. The nine least-significant bits are the standard Unix rwxrwxrwx permissions. The values of these bits should be considered part of the public API and may be used in wire protocols or disk representations: they must not be changed, although new bits might be added.

Is this a limitation of go?

What did you expect to see?

7777

What did you see instead?

0777

closed time in a day

luke-goddard

issue commentgolang/go

Os.Stat() File permissions representation

The Perm method is documented as returning the permission bits. The SUID bit is not a permission bit.

luke-goddard

comment created time in a day

issue closedianlancetaylor/libbacktrace

Remove generated files from git

The git repository contains many files that are generated and shouldn't be stored in git.

configure, aclocal.m4, all of config/, and so on.

closed time in a day

rossburton

issue commentianlancetaylor/libbacktrace

Remove generated files from git

The contents of the config directory are not generated.

In any case, this is intentional. It makes it possible to build the library without having to first install autoconf, automake and libtool. It also means that people who don't want to adjust the configury get a tested build.

rossburton

comment created time in a day

issue closedgolang/go

time: different time.Now().UTC() values between OS flavors

What version of Go are you using (go version)?

<pre> $ go version go version go1.13.8 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

Just saw the 1.14 release on twitter land, I shall try this shortly

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="on" GOARCH="amd64" GOBIN="" GOCACHE="/Users/iamnande/Library/Caches/go-build" GOENV="/Users/iamnande/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/iamnande/src/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/Cellar/go/1.13.8" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.13.8/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/dev/null" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/jd/4psb1_w93tsck8n25hnjl7k40000gn/T/go-build103114280=/tmp/go-build -gno-record-gcc-switches -fno-common" </pre></details>

What did you do?

given the following code in time.go:

package main

import (
	"fmt"
	"time"
)

func main() {
	fmt.Println(time.Now().UTC())
}

and the following Dockerfile:

FROM golang:1.13.8-alpine

WORKDIR /go/src/app
COPY . .

RUN go get -d -v ./...
RUN go install -v ./...

CMD ["app"]

you can run the following steps (within the workdir):

  1. go run time.go
  2. docker build -t time-test . && docker run -it --rm --name time-test time-test

and you will yield two different results; same time, however different levels of specificity.

  1. go run time.go yields: 2020-02-25 23:09:23.59933 +0000 UTC (darwin)
  2. docker time.go yields: 2020-02-25 23:09:50.499543766 +0000 UTC (alpine)

What did you expect to see?

I would expect to see the same level of accuracy within both implementations however...

What did you see instead?

I get microsecond accuracy on darwin vs nanosecond accuracy on alpine.

I did find this stackoverflow Q&A on the topic of accuracy in my searches: https://stackoverflow.com/questions/14610459/how-precise-is-gos-time-really

This is really more of a question of how I should be handling validating timestamps. Right now we're using the testify/assert package but I suppose we could deserialize and use [t.Equal()] for true timestamp validation (https://golang.org/pkg/time/#Time.Equal).

closed time in a day

iamnande

issue commentgolang/go

time: different time.Now().UTC() values between OS flavors

Darwin and Alpine are entirely different operating systems with entirely different kernels. There is no particular reason to think that they will provide the same timestamp precision. Go is just providing the best information that it has, so this difference doesn't really have anything to do with Go.

I'm not sure what you mean by "validating timestamps." You will get a better answer for that kind of question on a forum; see https://golang.org/wiki/Questions.

iamnande

comment created time in a day

issue commentgolang/go

proposal: Go 2: integrated compile time language

This proposal is incomplete in that it doesn't explain the compile time language. If it did, the additional complexity added to Go, as discussed above, would mean that we will not adopt it. Based on emoji voting, this proposal does not have strong support. Therefore, this is a likely decline. Leaving open for four weeks for final comments.

jonperryman

comment created time in a day

issue commentgolang/go

proposal: Go 2: implement an interface based on function signature if method name is ambiguous

As mentioned above, the current language rule is very simple and easy to understand: methods are matched by name, and nothing else.

Without examples of real code that would be significantly helped, we aren't going to make this change. Therefore, this is a likely decline. Leaving open for four weeks for final comments.

beoran

comment created time in a day

issue commentgolang/go

strings: Title and ToTitle have similar names but do different things

Maybe the names are poorly chosen but they do exist, they do work, and they are documented. It's not worth changing at this point. Even for Go 2 we don't want to arbitrarily break existing code.

(If we do anything here, personally I think we should deprecate strings.Title. I doubt it is widely used. But perhaps I am wrong.)

opennota

comment created time in a day

issue closedgolang/go

strings: Title and ToTitle have similar names but do different things

Title returns a copy of the string s with all Unicode letters that begin words mapped to their Unicode title case.

ToTitle returns a copy of the string s with all Unicode letters mapped to their Unicode title case.

Ideally (Go2) they should have completely different names.

closed time in a day

opennota

issue closedgolang/go

proposal: Go 2: time: deprecate time.Tick(d Duration)

Proposal Summary

Deprecate time.Tick(d) in favour of time.NewTicker(d). It's a very special case, where the ticker never stops and the channel cannot be recovered by the garbage collector. The name time.Tick() does not reflect it and if you really want that same functionality, it's just time.NewTicker(d).C, with the exception when d <= 0.

Would you consider yourself a novice, intermediate, or experienced Go programmer?

Intermediate

What other languages do you have experience with?

Comfortable with C, Python, JavaScript, PHP, C#, Lua.

Would this change make Go easier or harder to learn, and why?

Easier, by applying the principle of least astonishment. We can see that this function is already abused in some public repositories.

Has this idea, or one like it, been proposed before?

To my knowledge, no.

Who does this proposal help, and why?

The newcomers to Go as it will decrease ambiguity. We can see that there were issues in the past (#11662, #17757) and you can find public repositories (in GitHub, for instance), where this function is used improperly.

What is the proposed change?

Mark the function time.Tick() as deprecated in the standard library documentation and remove it in a later version. It won't introduce changes to the language specification.

Is this change backward compatible?

It is breaking the Go 1 compatibility guarantee. Thus, this proposal is labeled Go2.

Show example code before and after the change.

Before

for t := range time.Tick(d) {
  // loop body
}

After

for t := range time.NewTicker(d).C {
  // loop body
}

What is the cost of this proposal?

It probably breaks more than a few packages and binaries, which use that function. No compile time or runtime cost.

I've based the proposal on the language change template, but I have removed the last few points I found to be irrelevant.

closed time in a day

metala

issue commentgolang/go

proposal: Go 2: time: deprecate time.Tick(d Duration)

Proposal withdrawn.

metala

comment created time in a day

issue commentgolang/go

proposal: Go 2: simplify error handling - error passing with "pass"

It seems that pass v requires v to have type error and is shorthand for

    if v != nil {
        return ..., v // here ... is the zero value for the other result parameters
    }

It's unfortunate that error wrapping requires calling the function even when the error is nil, but on the other hand it would not be too hard for the compiler to check whether the wrapper function starts with

    if err == nil {
        return nil
    }

and pull those lines into caller without inlining the whole function.

The name pass is certainly used as a variable name in existing code (e.g., https://golang.org/src/crypto/sha512/sha512_test.go#L664), and that code would break.

Also the name pass doesn't seem to really describe the operation here. The word "pass" often means to pass over something, but in this case we are--passing it up to the caller? Passing over the rest of the function? I'm not sure.

One possibility would be to use return? or return if instead of pass.

    return? err
    return if err

As you know, there has been a lot of discussion about error handling in Go. Is this language change big enough for the problem? It saves about six tokens and two lines. Is that worth the cost of a language change?

xbit

comment created time in a day

issue commentgolang/go

Proposal: Allow function to satisfy interface while returning interface superset

The language doesn't support covariant returns in interface results, and that is an intentional decision as discussed in the FAQ. Therefore, this proposal is a likely decline. Leaving open for four weeks for final comments.

phemmer

comment created time in a day

issue commentgolang/go

proposal: Go 2: permit using errors.Return, etc., on LHS of an error assignment

We don't understand your example code. The after code doesn't seem to correspond to the before code.

We would need an exact and complete list of available options. Things like errors.Return and errors.Info seem very different: one affects control flow and the other does not. We don't know what errors.CustomSentAlert means. The example suggests that info somehow corresponds to errors.Info; how?

-- for @golang/proposal-review

iamjameslove

comment created time in a day

issue commentgolang/go

Proposal: Go 2: add C# like nameof() built-in function

While it may be true that using nameof makes the logrus example easier to refactor, that isn't normally the most important characteristic of a piece of code. Readability is normally more important than ease of refactoring. So the example still doesn't seem entirely convincing.

Keeping the name of a function and a string description in a test seems fairly minor.

We can't really use nameof for things like runtime/select.go where the runtime and the compiler have to be in synch. For that we should use code generation, instead. We already do that partially, in cmd/compile/internal/gc/runtime, and we could do more of it if we wanted to.

Still looking for clearer examples of where this is really useful.

It's also worth noting that the ease of refactoring due to nameof can in some cases introduce a problem. If an exported name is based on a nameof, then renaming an internal name may surprisingly change the external API in an invisible way. This may not be too likely but it's worth considering.

beoran

comment created time in a day

issue commentgolang/go

proposal: Go 2: decorator support, like python decorator

No further comments.

liamylian

comment created time in a day

issue commentgolang/go

proposal: Go 2: obtain struct field name in type-safe way

No change in consensus, so closing.

lifeng1992

comment created time in a day

issue closedgolang/go

proposal: Go 2: obtain struct field name in type-safe way

type Target struct {
    Name     string
    Path     string
    Date     time.Time
}

func main()  {
    ^Target{Name, Path} // equivalent []string{"Name", "Path"}
    ^Target{}.Name // equivalent "Name"
}

Good point

  • compatible with Go 1.x
  • just syntactic sugar
  • refactor friendly
  • avoid typo

closed time in a day

lifeng1992

issue closedgolang/go

proposal: Go 2: decorator support, like python decorator

Decorator may make writing GoLang projects more efficient. I hope GoLang support some kind of decorator.

// decorator `Default` sets default value to a int variable
func (intVar *int) @Default(value int) {
	if intVar == nil || *intVar == 0 {
		intVar = &value
	}
}

// decorator `Route` adds route to a `HandlerFunc`
func (handler http.HandlerFunc) @Route(method, uri string) {
	http.HandleFunc(uri, handler)
}

@Route(method = http.MethodGet, uri = "/books/:id") // decorator `Route` run right after function `getBook` is defined. That is, `getBook.Route(http.MethodGet, "/books/:id")` will be called right after function `getBook` is defined. 
func getBook(w http.ResponseWriter, r *http.Request) error {
	return nil
}

func main() {
	@Default(value = 80) // `httpPort.Default(80)` will be called right after variable `httpPort` is initialized 
	var httpPort int

	http.ListenAndServe(fmt.Sprintf(":%d", httpPort), nil)
}

closed time in a day

liamylian

issue closedgolang/go

proposal: new builtin to pick from one of two values

Consider a builtin called pick that can pick from one of two given values of the same type, depending on a boolean expression:

// before
var v string
if expr {
    v = "value1"
} else {
    v = "value2"
}

// after
v := pick(expr, "value1", "value2")

Yes, it is yet another ternary operator proposal :-), but this time suggested as a builtin similar to append or delete.

The signature of pick would look like:

func pick(cond bool, lhs, rhs Type) Type

where Type is any(?) type and the compiler would enforce that lhs, rhs and the return value are of the same type - similar to how the 2nd and later arguments of append and the return value are of the same type.

Only one of the arguments would be evaluated depending on the result of the boolean expression, similar to an if-else statement.

As for evidence that this can simplify code, here are some examples, all taken from the single Go source code file fmt/format.go:

lines 76-80:

// before
	// Decide which byte the padding should be filled with.
	padByte := byte(' ')
	if f.zero {
		padByte = byte('0')
	}

// after
    padByte := byte(pick(f.zero, '0', ' '))

lines 124-132:

// before
func (f *fmt) fmtBoolean(v bool) {
	if v {
		f.padString("true")
	} else {
		f.padString("false")
	}
}

// after
func (f *fmt) fmtBoolean(v bool) {
    f.padString(pick(v, "true", "false"))
}

lines 370-374:

// before
	length := len(b)
	if b == nil {
		// No byte slice present. Assume string s should be encoded.
		length = len(s)
	}

// after
    length := pick(b == nil, len(s), len(b))

lines 419-423:

// before
		if b != nil {
			c = b[i] // Take a byte from the input byte slice.
		} else {
			c = s[i] // Take a byte from the input string.
		}

// after
    c = pick(b != nil, b[i], s[i])

lines 454-458, also lines 481-485:

// before
	if f.plus {
		f.pad(strconv.AppendQuoteToASCII(buf, s))
	} else {
		f.pad(strconv.AppendQuote(buf, s))
	}

// after
    f.pad(pick(f.plus, strconv.AppendQuoteToASCII(buf, s), strconv.AppendQuote(buf, s))

lines 464-467, also lines 476-479:

// before
	r := rune(c)
	if c > utf8.MaxRune {
		r = utf8.RuneError
	}

// after
    r := pick(c > utf8.MaxRune, utf8.RuneError, rune(c))

lines 526-531:

// before
			digits = prec
			// If no precision is set explicitly use a precision of 6.
			if digits == -1 {
				digits = 6
			}

// after
    digits = pick(digits == -1, 6, prec)

closed time in a day

mdevan

issue commentgolang/go

proposal: new builtin to pick from one of two values

No change in consensus, so closing.

The pick proposal seems like an entirely different proposal. Let's do that in a separate issue if someone wants to pursue it.

mdevan

comment created time in a day

issue commentgolang/go

time: racy Timer access should either work or throw, not panic

Just to be clear, the problem was not introduced in 1.11. The program above also fails with 1.10. What happened in 1.11 was that the problem changed from a throw saying "fatal error: panic holding locks" to a panic saying "runtime error: racy use of timers". Changing from a throw to a panic was a mistake on my part. But changing from "panic holding locks" to "racy use of timers" was not.

Before 1.10 the problem still exists but is harder to reproduce. What changed in 1.10 was that we switched to many different timer buckets. With fewer timers in each bucket it's easier to create a case in which siftupTimer gets an index out of range.

In any case we can do better with the new timers.

bcmills

comment created time in 2 days

issue commentgolang/go

proposal: runtime: mechanism for monitoring system memory

See also #33060.

NatoBoram

comment created time in 2 days

issue commentgolang/go

cmd/vet: warn about string(int) type conversions

Thanks. I sent CLs to fix those cases.

ianlancetaylor

comment created time in 2 days

IssuesEvent

issue commentgolang/go

os/exec: environForSysProcAttr is never called as sysattr.Env is never nil

Gopherbot opened for 1.12 and 1.13, reopening this issue for 1.14.

LiamHaworth

comment created time in 2 days

issue commentgolang/go

os/exec: environForSysProcAttr is never called as sysattr.Env is never nil

I have no idea.

@gopherbot Please open backport issues

This may be security related on Windows systems.

LiamHaworth

comment created time in 2 days

issue commentgolang/go

Invalid tool command or web page or both?

As far as I can tell go tool api exists on tip and in Go 1.13. How did you build your Go installation?

ronaldpetty

comment created time in 2 days

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

I suppose I'm asking for opinions.

Is it worth complicating the testing package to return from m.Run if a panic occurs directly in the test, given that we can't do that if a test start a goroutine that panics?

orlangure

comment created time in 2 days

GollumEvent

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

Would somebody who understands the details like to update https://golang.org/wiki/MinimumRequirements? Thanks.

artooro

comment created time in 3 days

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

@artooro What version of FreeBSD are you using?

artooro

comment created time in 3 days

issue commentgolang/go

proposal: cmd/gofmt: minimize adjacent whitespace changes on struct layout edits

It's not obvious to me that editors and revision control per-submit hooks need to know the go 1.xx directive. Why would they?

The implication that this change would cause massive changes sounds like a good reason to not do it. Why is the benefit worth the cost?

ohir

comment created time in 3 days

issue commentgolang/go

testing: when using a custom TestMain, m.Run does not return if one of the tests it runs panics

We can never make this perfect. If some code in a test calls

    go func() { panic("die die die") }()

then m.Run is not going to return no matter what we do.

The only question here is how we should handle a test that panics in the goroutine used to run the test. Should we try to handle that specific case? Or should we just treat it like a panic in a different goroutine, which is in effect what we do now?

I don't have a strong opinion about that. But the testing package is already fairly baroque. Is it really worth complicating it further to handle one specific case when we can't handle other similar cases?

orlangure

comment created time in 3 days

issue closedgolang/go

cmd/vet or golint: Catch TestMain without os.Exit

Saw someone do this today:

func TestMain(m *testing.M) { m.Run() }

which, naturally, gives false positives for test success.

closed time in 3 days

tv42

issue commentgolang/go

cmd/vet or golint: Catch TestMain without os.Exit

Thanks.

tv42

comment created time in 3 days

issue commentgolang/go

proposal: cmd/gofmt: minimize adjacent whitespace changes on struct layout edits

Having choices of formatting based on directives in go.mod does not strike me as a good idea. gofmt is invoked in many different environments by different editors, revision control import hooks, etc. To require all those environments to preserve the go.mod directive is a big ask. And the benefit seems small.

If we're going to change the formatting, let's change the formatting.

(And then let's decide that gofmt is imperfect but is good enough, and let's not change the formatting. But that's just an opinion, not an argument.)

ohir

comment created time in 3 days

IssuesEvent

issue commentgolang/go

time: add Ticker.Reset

CL reverted due to test failures, so reopening.

zero-go

comment created time in 4 days

issue commentgolang/go

time: unexpected error in Parse when parsing January 31st (day 031) using "002" day of year format

Ouch, thanks for reporting that. I will send a patch.

LDiegoM

comment created time in 4 days

issue commentgolang/go

x/lint: recommend parameters in func type signatures

I agree that naming the parameters would not break compatibility. That wasn't my point. My point is that as a general rule lint should not emit any warnings for well written idiomatic Go code. We think that the Go code in the standard library is well written and idiomatic. So the fact that the proposed warning would trigger on code in the standard library is a mark against it.

l0k18

comment created time in 4 days

issue commentgolang/go

x/lint: recommend parameters in func type signatures

Two of the examples I cited from the standard library are not internal functions, as you can see from their names.

l0k18

comment created time in 4 days

issue commentgolang/go

x/lint: recommend parameters in func type signatures

This suggestion doesn't seem to fit with the scope section of https://go.googlesource.com/lint/+/refs/heads/master/README.md. It would also cause lint warnings in a few places in the standard library, such as matchStringOnly in testing/testing.go or Filter in go/ast/filter.go or HandlerFunc in net/http/server.go. Linter warnings in the standard library aren't the worst thing, but they suggest that there is perfectly reasonable code that doesn't use function parameter names in func types, and we don't want to have linter warnings for perfectly reasonable code.

I suggest that you use your own tool for this, perhaps based on lint, to give warnings for code that violates your preferred style. It doesn't seem like something appropriate for the general purpose tool.

l0k18

comment created time in 4 days

issue closedgolang/go

x/crypto/ssh: Race Conditions on Channel EOF, Closing and Request Processing

What version of Go are you using (go version)?

go version go1.11.4 linux/amd64

Does this issue reproduce with the latest release?

Yes, x/crypto/ssh on master

What did you do?

We have a large codebase that is acting as a ProxyCommand. Our code acts as a bridge, being both a client and server. When running under Ansible, which spawns OpenSSH with ControlMaster enabled and heavily leverages “pipelining” of Ansible commands, we have encountered a race condition in the processing of a Channel.

In mux.go, there is a tight loop for processing messages: https://github.com/golang/crypto/blob/ff983b9c42bc9fbf91556e191cc8efb585c16908/ssh/mux.go#L189-L191

Eventually, this calls ch.handlePacket: https://github.com/golang/crypto/blob/ff983b9c42bc9fbf91556e191cc8efb585c16908/ssh/channel.go#L398

Three messages are received quickly on a session channel:

  • exit-status
  • eof
  • close

Each message is handled differently:

  • exit-status is made into a Request and sent to ch.incomingRequests. (goroutine A)
  • eof sets .eof() on the buffer, which triggers any Readers of the buffer (stdout, stderr) to stop. (goroutine B)
  • close is handled internally. (goroutine C)

When writing these “back” to our outbound channel, we must make calls in a specific order, so that the messages on the wire go out in the same order as we received them. In our ideal world, our proxy code, we should call these in order:

  • SendRequest() for exit-status
  • .CloseWrite() on the channel (generating eof messages)
  • .Close() on the channel (generating close)

However, this is extremely difficult, and our code had race conditions because we’re processing the Channel IO and Requests in their own goroutines. In the “bad” path of the race condition, we would:

  • Inbound channel Read() would return EOF, so we would call .CloseWrite() on the outbound channel, generating an EOF message to the Outbound Channel.
  • We would then RECEIVE a Close from the Outbound Channel -- this would cause the internal handling to completely close the channel
  • Inbound channel reading from the ->Requests Go-Channel would process the exit-status Request, and fail to write it to the outbound channel, because the outbound channel has already been hard closed.
  • Ansible / OpenSSH would then break the ControlMaster muxing because it was expecting to receive an exit-status message, but never does, causing an error message like this:
debug3: mux_client_read_packet: read header failed: Broken pipe
debug2: Control master terminated unexpectedly

Using Go-channels and a Read() interface at the same time, requires processing across at least two goroutines. Additionally, because close messages are internally handled, there is a 3rd goroutine making races harder to control. Ordering of receiving messages is lost and hard to guarantee.

What did you expect to see?

I would prefer that all operations were written to a single Go-channel. (Data and Requests, including the Close message). This would allow in-order processing of a SSH Channel. This could maybe be written as an intermediate layer, and the current public API could be changed to run on top of it?

Relevant Logs

2019/01/11 11:39:35 decoding(1): data packet - 16393 bytes
2019/01/11 11:39:35 send(1): ssh.windowAdjustMsg{PeersID:0x0, AdditionalBytes:0x4000}
2019/01/11 11:39:35 decoding(1): data packet - 8201 bytes
2019/01/11 11:39:35 decoding(1): data packet - 1010 bytes
2019/01/11 11:39:35 send(1): ssh.windowAdjustMsg{PeersID:0x0, AdditionalBytes:0x23e9}
2019/01/11 11:39:35 decoding(1): 98 &ssh.channelRequestMsg{PeersID:0x1, Request:"exit-status", WantReply:false, RequestSpecificData:[]uint8{0x0, 0x0, 0x0, 0x0}} - 25 bytes
2019/01/11 11:39:35 decoding(1): 96 &ssh.channelEOFMsg{PeersID:0x1} - 5 bytes
2019/01/11 11:39:35 decoding(1): 97 &ssh.channelCloseMsg{PeersID:0x1} - 5 bytes
2019/01/11 11:39:35 send(1): ssh.channelCloseMsg{PeersID:0x0}
2019/01/11 11:39:35 send(2): ssh.channelEOFMsg{PeersID:0x2}
2019/01/11 11:39:35 decoding(2): 97 &ssh.channelCloseMsg{PeersID:0x2} - 5 bytes
2019/01/11 11:39:35 send(2): ssh.channelCloseMsg{PeersID:0x2}
2019/01/11 11:39:35 send(2): ssh.channelRequestMsg{PeersID:0x2, Request:"exit-status", WantReply:false, RequestSpecificData:[]uint8{0x0, 0x0, 0x0, 0x0}}
2019/01/11 11:39:35 send(2): ssh.channelCloseMsg{PeersID:0x2}
2019/01/11 11:39:35 send(1): ssh.channelCloseMsg{PeersID:0x0}

closed time in 4 days

paulquerna-okta

issue commentgolang/go

x/crypto/ssh: Race Conditions on Channel EOF, Closing and Request Processing

There are no updates. Based on the comments above, I don't think we are going to change anything here. I'm going to close this issue. Please comment if you disagree.

paulquerna-okta

comment created time in 4 days

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

CC @Mikaelurankar @bsd-hacker @myfreeweb

artooro

comment created time in 5 days

issue commentgolang/go

proposal: spec: add &T(v) to allocate variable of type T, set to v, and return address

I don't see any clear consensus in the discussion above. Although the emoji voting on &T(v) is good, there are quite a few comments suggesting other approachs.

It's also worth considering that the generics design draft permits writing

package addr

func P(type T)(v T) *T {
    return &v
}

which can then be used as

    p1 := addr.P(1) // p1 has type *int
    p2 := addr.P(iint64(2)) // p2 has type *int64
    p3 := addr.P("hi") // p3 has type *string
    p4 := addr.P(time.Now()) // p4 has type *time.Time

This has some advantages, in that it doesn't require a new language feature (well, doesn't require a language feature other than generics), and it doesn't require writing the type when that is not needed.

So personally I would be inclined to wait until we have generics to see if an approach like that seems sufficient.

chai2010

comment created time in 5 days

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

Thanks.

Does anybody know why that instruction would trigger an illegal instruction interrupt? As far as I can tell it should be supported on any ARMv8 processor. Is it a privileged instruction?

CC @cherrymui @4a6f656c @tklauser @4ad

artooro

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: permit converting a string constant to a byte array type

As far as I know the gc compiler doesn't have the "24 byte problem." And, if it does, we should treat as something to fix in the compiler, rather than something to fix in the language.

(As I mentioned above I'm not opposed to this change, I just don't think that optimization is a reason for it.)

jfcg

comment created time in 6 days

issue commentgolang/go

proposal: x/crypto/ssh/terminal: move all APIs to x/term and deprecate

A maintainer is someone with experience with the code who is willing to take responsibility for reviewing contributions and fixing issues related to the code.

tandr

comment created time in 6 days

issue commentgolang/go

reflect: Select panics if array length greater than 1<<16

Ah, thanks, I hadn't noticed that.

Given that I'm OK with the restriction, and I just think that we need 1) documentation; 2) a better panic message.

theMPatel

comment created time in 6 days

issue commentgolang/go

Unreachable "break" in switch statement causes erroneous compiler static analysis

I think the most important point in this area is that we keep the rules for terminating statements simple, so that all compilers can simply and easily agree as to which statements terminate and which do not. I think that is much more important than handling cases like return; break. Admittedly humans can easily see that the break is not relevant, but writing down simple rules for that is less easy.

Also, return; break is simply not common Go code.

So my preference here would be to do nothing.

fsufitch

comment created time in 6 days

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

Thanks. Please use x/i $pc to see the exact instruction.

artooro

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: type annotation `~` for stack allocated variables

I'm not sure I understand what you are saying. The point I'm trying to make is that when calling a method of an interface type the compiler cannot always know exactly which method is being called. Therefore it has no escape analysis information at all.

Functions constructed using reflect.MakeFunc are very rare, but they still have to work correctly. It's just another example where the compiler cannot know, when calling a function, whether the value escapes or not.

JOT85

comment created time in 6 days

issue commentgolang/go

encoding/json: document change in Number behavior for 1.14

The point of the Google example is that no internal Google tests broke with this change, including tests that used third libraries written outside of Google. That suggests that there isn't all that much code that depends on this specific behavior.

I haven't really looked into this issue. But when considering a change in undocumented behavior, it is absolutely relevant how many failure cases there are. Backward compatibility is very important, but we also have to be able to fix bugs.

marwan-at-work

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: permit converting a string constant to a byte array type

Both byte slices and byte arrays have an array of bytes. We can disregard that when comparing them.

A byte slice is three different values: a pointer to the array of bytes, a length, and a capacity. A byte array will internally be represented using a pointer to the array, and a constant length. When the compiler sees []byte("abc") it knows that the length and capacity are 3, so they are also constant, just as with a byte array. So internally when the compiler is working with a byte slice initialized in that way, it has a pointer to an array, and a constant length and capacity. In other words, it's just the same as an array.

The 24 bytes only arises when the compiler has to construct the slice in memory. In practice that only happens if the slice is converted to an interface type. When the slice is indexed, the compiler can compare the index with the length, in this case a constant. When the slice is passed to a function, the compiler will pass three separate values, where in this case two of them are constants. The compiler does not need to construct a 24 byte value in order to do that (the arguments to the function will take 24 bytes, but exactly the same would happen when passing a byte array to a function that expects a byte slice, by slicing the array).

In other words, the compiler doesn't think of a byte slice as a single value of size 24 bytes. It thinks of it as three different values, one pointer and two ints. Only when the slice must be stored into memory, as when converting to an interface type or setting a global variable, does the compiler need to assemble the 24 byte value.

jfcg

comment created time in 6 days

issue commentgolang/go

proposal: default implementation of io.ByteReader from io.Reader

NopCloser was added to the standard library because external packages kept repeating that code. It made sense to consolidate a single version.

It's not clear to me that external package keep repeating the creation of an io.ByteReader. For most uses a bufio.Reader works well and is more efficient. The case where people want the less efficient, albeit smaller, io.ByteReader seems uncommon to me. But I might change my mind if there are many existing examples where programs have chosen to implement a small io.ByteReader.

pierrec

comment created time in 6 days

issue commentgolang/go

runtime: TestCgoPprofPIE is flaky

Maybe we should simply disable signal-based preemption when running the test. The point of the test is just to see that we pick up a stack trace for SIGPROF, disabling signal-based preemption doesn't invalidate what we are testing for.

bcmills

comment created time in 6 days

issue commentgolang/go

fatal: morestack on g0 while running a server for half-year

A g0 should never run out of stack space and should never call morestack. Something has gone wrong. If this is not repeatable, then I would suspect memory corruption.

(That said, it might perhaps be possible for a g0 to run out of stack space if there is a deeply recursive sequence of Go code calling C code calling Go code calling C code, etc. I haven't tried.)

absolute8511

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: permit implicit conversion of constants to pointer types

I would be inclined to push on #9097 before adding such a package to the standard library.

abuchanan-nr

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: type annotation `~` for stack allocated variables

Of course if the decision can be made at compile time, then we should do that. But it's not hard to imagine cases in which the compiler cannot possibly determine whether a value passed to a method of an interface escapes. Or consider passing a slice to a func([]byte) that is constructed using reflect.MakeFunc.

JOT85

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: permit converting a string constant to a byte array type

The discussion about "24 bytes of waste" is assuming specific compiler behavior. It's misleading because compilers can change. In the example above it's true that buf is likely to be allocated as 24 bytes on the stack in order to get a value to pass to fmt.Println. But it's also true that using a byte array is likely to cause two copies of the array to exist, in order to get a separate copy of the array to pass to fmt.Println. Exactly what happens is going to depend deeply on what the compiler is able to do. If the compiler never needs to store the capacity of a slice anywhere, then perhaps it won't. If the compiler never needs to copy an array, then perhaps it won't.

In general, we should avoid making language decisions based on compiler behavior.

(Which is not to say that I am opposed to this change, but if there is a reason to do it it has to do with making code simpler and more readable, and is not because of saving space on the stack.)

jfcg

comment created time in 6 days

issue commentgolang/go

proposal: spec: add decimal float types (IEEE 754-2008)

@tc-hib Thanks. I understand that floating point numbers behave in ways that people find surprising (https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html). That's not the question I was trying to ask.

typeless

comment created time in 6 days

issue commentgolang/go

reflect: Select panics if array length greater than 1<<16

If we do decide to panic on cases like this it for sure should not be a panic that just says "slice bounds out of range".

Personally I'm inclined to think that we should just support it. Yes, the performance will be bad. But relatively arbitrary limitations are bad in a different way. If the limit were billions I would feel differently. Thousands of cases doesn't seem inherently absurd.

theMPatel

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: type annotation `~` for stack allocated variables

Yes, I was imagining two sequences with choice based on metadata stored with the type descriptor in the interface. It's just a thought, I don't know what the code size explosion would be.

JOT85

comment created time in 6 days

issue commentgolang/go

bufio: panic: tried to fill full buffer after calling Reset

Why not just call bufio.NewReader with a dummy io.Reader, such as bytes.NewReader(nil)? I'm not sure we want to support bufio.NewReader(nil). And I'm not sure we want to support new(bufio.Reader).

aka-rider

comment created time in 6 days

GollumEvent

issue commentgolang/go

cmd/link: unexpected fault address (when low on disk space?)

I haven't looked at the code, but if we're going to mmap the output file, we should fallocate it first. Otherwise, it's possible for the program to exit after writing all blocks to the memory mapped area, calling munmap and close, but before disk blocks have been assigned. In that case the generated executable may be incomplete, which is bad. Or, of course, we can get a SIGBUS during execution which is less bad but still bad. The fix is to either fallocate or fdatasync, and fallocate is faster.

bradfitz

comment created time in 6 days

issue commentgolang/go

runtime: TestCgoPprofPIE is flaky

The test doesn't count the number of profiling samples that are taken. It counts the number of times the pprofCgoTraceback function is called. That function is called any time a signal occurs while executing in non-Go code. Before we started using signal based preemption, the only signal that would occur in non-Go code was SIGPROF. Now we can also see SIGURG. That is not a bug. But it means that this test is flaky: if we see two SIGURG signals in non-Go code before we see any SIGPROF signals in non-Go code, the test will fail.

So I don't think there is a fundamental problem here. It's a problem with the way that the test is written. It's not a problem that would happen with real code.

Unfortunately I don't see a simple fix off hand, other than disabling signal based preemption for the test.

bcmills

comment created time in 6 days

issue commentgolang/go

proposal: default implementation of io.ByteReader from io.Reader

As you show, you can already do this yourself. So the only question is whether this should be in the standard library. Is this really something that comes up often enough to add to the standard library? https://golang.org/doc/faq#x_in_std

pierrec

comment created time in 6 days

issue commentgolang/go

proposal: unsafe: add Slice and String types, conversions to replace reflect.{Slice,String}Header

A case that this would help in the standard library: #37350.

mdempsky

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: type annotation `~` for stack allocated variables

It seems to me that this language change has no effect on how the program runs. It only affects efficiency.

The language currently permits people to write code without worrying about whether values are allocated on the stack or the heap. Adding this feature to the language will lead people to start thinking about it. That seems like a significant increase in complexity. As you say, the feature requires quite a lot of understanding. One can say that nobody has to use the feature, which is true, but in practice people will use it, and other people will need to read, understand, and modify their code, so in practice everybody will need to understand it.

In general in Go we prefer to keep the language simple and to put complexity into the implementation. The runtime has do quite a lot of work to present the relatively simple interface of goroutines and channels. And, for that matter, to avoid the possibility of dangling pointers while keeping memory usage and execution time fairly good.

In my opinion before considering adding this kind of feature to the language we should put a lot of effort into trying to implement it in the compiler and runtime. The key feature here is whether the compiler can prove that a call to an interface method does not escape. I can imagine using whole program optimization for this, or perhaps selecting between alternative code sequences based on information supplied by the implementation. Perhaps those ideas will turn out to be unworkable, but I think we should be putting our effort there rather than into a language change that increases complexity.

JOT85

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: permit implicit conversion of constants to pointer types

If we are going to permit an untyped constant to convert to a pointer type, then p == 0 (where p has some pointer type) will also be permitted. If that is not permitted, then we would need to introduce a new concept to the language, to describe the cases that permit implicit conversion to pointer types and the cases that do not. Unfortunately p == 0 will not behave as anybody expects; it will allocate a new memory location, set it to 0, and then compare the address of that location to p. In other words p == 0 will always be false.

The non-constant case comes up with code like

	rec := Record{
		Name:   CurrentUser()
		Income: 42.0 + baseIncome(),
	}
abuchanan-nr

comment created time in 6 days

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

Can you run the program under gdb to find out exactly what the illegal instruction is?

artooro

comment created time in 6 days

issue commentgolang/go

proposal: Go 2: permit implicit conversion of constants to pointer types

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

abuchanan-nr

comment created time in 7 days

issue commentgolang/go

proposal: Go 2: permit implicit conversion of constants to pointer types

In general Go avoids implicit conversions, as they can easily cause confusion. I believe the only implicit conversions in Go are from values of some defined type to an interface that that defined type implements. Also constants are untyped and as such can be used with a range of compatible types.

Also, if we are going to do this implicit conversion, why restrict it to constants? I agree that constants are a common case, but the same issues arise with values held in variables.

abuchanan-nr

comment created time in 7 days

more