Skip to content

x/sys/unix: expose signal and errno names as strings #25134

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
AlekSi opened this issue Apr 27, 2018 · 7 comments
Closed

x/sys/unix: expose signal and errno names as strings #25134

AlekSi opened this issue Apr 27, 2018 · 7 comments
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge
Milestone
Unreleased

Comments

@AlekSi
Copy link
Contributor

AlekSi commented Apr 27, 2018

Currently, signal and errno names are represented by the following generated Go code (abbreviated):

const (
  SIGINT = syscall.Signal(0x2)
)

const (
  EAGAIN = syscall.Errno(0xb)
)

var signals = [...]string{
  2: "interrupt",
}

var errors = [...]string{
  11: "resource temporarily unavailable",
}

There is no way to get back signal or errno name (SIGINT and EAGAIN) from the number for, for example, nice logging messages.

I propose to expose them via two functions:

func SignalName(s syscall.Signal) string { }
func ErrnoName(e syscall.Errno) string { }

That's something that annoyed me for years, but I finally decided to create an issue.
@gopherbot gopherbot added this to the Unreleased milestone Apr 27, 2018
@agnivade agnivade added the FeatureRequest Issues asking for a new feature that does not need a proposal. label Apr 28, 2018
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/110156 mentions this issue: zerros: Expose functions to get back names from the number

@tklauser
Copy link
Member

Sounds fine to me. It would be nice if we had unix.Errno and unix.Signal types (not sure why these were not converted in the initial x/sys package split). We could then even have

func (s Signal) Name() string { ... }
func (e Errno) Name() string {... }

@ianlancetaylor @bradfitz what do you think?

@ianlancetaylor
Copy link
Member

I think we would still want SignalName and ErrnoName, for use with the standard library. It seems a little confusing to require people to convert to unix.Signal or unix.Errno.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/110875 mentions this issue: unix: add ErrnoName and SignalName

@kolyshkin kolyshkin mentioned this issue Oct 4, 2018
Closed
@kolyshkin
Copy link
Contributor

@tklauser it seems that zerrors_linux_sparc64.go is not converted to the new format.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/139977 mentions this issue: unix: convert errorList and signalList to new format for linux/sparc64

@tklauser
Copy link
Member

tklauser commented Oct 5, 2018

@kolyshkin uh, I forgot to change it there because linux/sparc64is not integrated with the Docker-based build system. I sent https://golang.org/cl/139977 to fix it. Thanks.

gopherbot pushed a commit to golang/sys that referenced this issue Oct 5, 2018
@tklauser
unix: convert errorList and signalList to new format for linux/sparc64
4497e2d 
This wasn't converted during CL 110875

Updates golang/go#25134

Change-Id: Iaa579e0c173d3e27cf9f7e20072752277089beb1
Reviewed-on: https://go-review.googlesource.com/c/139977
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@golang golang locked and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
6 participants
@AlekSi @tklauser @agnivade @ianlancetaylor @kolyshkin @gopherbot