你使用的Go版本是什么( go version
)?
$ go version
go version go1.15.7 windows/amd64
这个问题在最新版本的发布中是否会重现?
是的
你正在使用什么操作系统和处理器架构( go env
)?
go env
输出
$ go env
set GO111MODULE=
set GOARCH=wasm
set GOBIN=
set GOCACHE=C:\Users\User\AppData\Local\go-build
set GOENV=C:\Users\User\AppData\Roaming\go\env
set GOEXE=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\User\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=js
set GOPATH=C:\Users\User\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set GOWASM=
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-fPIC -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\User\AppData\Local\Temp\go-build540642258=/tmp/go-build -gno-record-gcc-switches
你做了什么?
代码:
package main
import "fmt"
import "io/ioutil"
import "os"
func main() {
bytes, err := ioutil.ReadAll(os.Stdin)
if err != nil {
fmt.Printf("err is %q\n", err.Error())
} else {
fmt.Printf("stdin is %q\n", string(bytes))
}
}
使用:
C:\Users\User\Desktop>set GOROOT=js
C:\Users\User\Desktop>set GOARCH=wasm
C:\Users\User\Desktop>go build -o main.wasm main.go
你期望看到什么?
C:\Users\User\Desktop>echo abc | node c:\go\misc\wasm\wasm_exec.js main.wasm
stdin is "abc \r\n"
你实际看到了什么?
C:\Users\User\Desktop>echo abc | node c:\go\misc\wasm\wasm_exec.js main.wasm
panic: <object>
goroutine 6 [running]:
syscall.mapJSError(0x7ff8000100000015, 0x418128, 0x160f0008, 0x7ff8000100000011)
c:/go/src/syscall/fs_js.go:552 +0x1e
syscall.fsCall.func1(0x0, 0x0, 0x432240, 0x3, 0x3, 0x418120, 0x40000430700)
c:/go/src/syscall/fs_js.go:507 +0xb
syscall/js.handleEvent()
c:/go/src/syscall/js/func.go:96 +0x24
这是由于node中的一个bug导致的,在Windows上, fs.read
的行为不正确。当它到达文件末尾时( <object>
是EOF错误对象),它会返回一个EOF错误。至少有两份报告包括 nodejs/node#35997 和 nodejs/node#19831 。
然而,我在这里报告这个问题是因为:a) 这个bug已经很旧了,所以在野外到处都是;b) 我认为Go很容易解决这个问题。我的建议解决方案是将来自 fs.read
的EOF错误视为 null
,这样应该可以避免恐慌并与Go在Unix上的操作行为相匹配。
1条答案
按热度按时间rta7y2nd1#
我在另一个案例中遇到了这个问题。根本原因是解析器目前仅适用于具有"code"Map的对象,具体可以参考:https://github.com/golang/go/blob/go1.19beta1/src/syscall/fs_js.go#L548-L554