Skip to content
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.

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

os: Binary data written to os.Stdout gets corrupted on Windows 8.1 #42337

Closed
twoi opened this issue Nov 2, 2020 · 3 comments
Closed

os: Binary data written to os.Stdout gets corrupted on Windows 8.1 #42337

twoi opened this issue Nov 2, 2020 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone

Comments

@twoi
Copy link

twoi commented Nov 2, 2020

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

$ go version
go version go1.13.8 linux/amd64

Does this issue reproduce with the latest release?

Yes (namely go version go1.15.3 linux/amd64)

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

I'm cross-compiling on Linux/amd64 (see the following go env output), and running on Windows 8.1/amd64:

go env Output
Build environment:
$ go env

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/twoi/.cache/go-build"
GOENV="/home/twoi/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/twoi/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.13"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.13/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build855756322=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Using

GOOS=windows GOARCH=amd64 go build main.go

I built the following program

package main

import "os"

func main() {
	os.Stdout.Write([]byte{65})
}

Then I ran it on cmd.exe on Windows 8.1 like so:

.\main > file

What did you expect to see?

A file containing the single byte 65 (i.e. 'A')

(On Unix and Windows 10 - running the very same main.exe build - this is indeed what I am seeing)

N.B. Both tested Windows 8.1. and Windows 10 were Japanese language Windows installations.

What did you see instead?

file was 8 bytes in size, containing the following bytes (hex dump):

00000000  ff fe 41 00 0d 00 0a 00                           |..A.....|

Here's the issue on Stackoverflow: https://stackoverflow.com/q/64639265/709537 (closed of course by the Stackoverflow Gestapo)

@toothrot toothrot changed the title Binary data written to os.Stdout gets corrupted on Windows 8.1 os: Binary data written to os.Stdout gets corrupted on Windows 8.1 Nov 2, 2020
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 2, 2020
@toothrot toothrot added this to the Backlog milestone Nov 2, 2020
@toothrot
Copy link
Contributor

toothrot commented Nov 2, 2020

/cc @alexbrainman

@networkimprov
Copy link

cc @mattn

@twoi
Copy link
Author

twoi commented Nov 4, 2020

It turns out my problem description was wrong.

In fact I get the same results for Windows 8.1. and Windows 10 when using cmd.exe, namely the expected 1 byte output. The problem is powershell, which gives the 8 byte output.

My bad - I am closing this. In powershell, I'm now successfully using cmd /c "cmd1 | cmd2" in order to pipe binary data.

@twoi twoi closed this as completed Nov 4, 2020
@golang golang locked and limited conversation to collaborators Nov 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
None yet
Development

No branches or pull requests

4 participants