go/src/os/export_windows_test.go

// Copyright 2016 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

package os

// Export for testing.

var (
	FixLongPath       = fixLongPath
	NewConsoleFile    = newConsoleFile
	CommandLineToArgv = commandLineToArgv
)
os: make readConsole handle its input and output correctly This CL introduces first test for readConsole. And new test discovered couple of problems with readConsole. Console characters consist of multiple bytes each, but byte blocks returned by syscall.ReadFile have no character boundaries. Some multi-byte characters might start at the end of one block, and end at the start of next block. readConsole feeds these blocks to syscall.MultiByteToWideChar to convert them into utf16, but if some multi-byte characters have no ending or starting bytes, the syscall.MultiByteToWideChar might get confused. Current version of syscall.MultiByteToWideChar call will make syscall.MultiByteToWideChar ignore all these not complete multi-byte characters. The CL solves this issue by changing processing from "randomly sized block of bytes at a time" to "one multi-byte character at a time". New readConsole code calls syscall.ReadFile to get 1 byte first. Then it feeds this byte to syscall.MultiByteToWideChar. The new syscall.MultiByteToWideChar call uses MB_ERR_INVALID_CHARS flag to make syscall.MultiByteToWideChar return error if input is not complete character. If syscall.MultiByteToWideChar returns correspondent error, we read another byte and pass 2 byte buffer into syscall.MultiByteToWideChar, and so on until success. Old readConsole code would also sometimes return no data if user buffer was smaller then uint16 size, which would confuse callers that supply 1 byte buffer. This CL fixes that problem too. Fixes #17097 Change-Id: I88136cdf6a7bf3aed5fbb9ad2c759b6c0304ce30 Reviewed-on: https://go-review.googlesource.com/29493 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> 2016-09-20 19:19:36 -06:00			`// Copyright 2016 The Go Authors. All rights reserved.`
			`// Use of this source code is governed by a BSD-style`
			`// license that can be found in the LICENSE file.`

			`package os`

			`// Export for testing.`

			`var (`
os: parse command line without shell32.dll Go uses CommandLineToArgV from shell32.dll to parse command line parameters. But shell32.dll is slow to load. Implement Windows command line parsing in Go. This should make starting Go programs faster. I can see these speed ups for runtime.BenchmarkRunningGoProgram on my Windows 7 amd64: name old time/op new time/op delta RunningGoProgram-2 11.2ms ± 1% 10.4ms ± 2% -6.63% (p=0.000 n=9+10) on my Windows XP 386: name old time/op new time/op delta RunningGoProgram-2 19.0ms ± 3% 12.1ms ± 1% -36.20% (p=0.000 n=10+10) on @egonelbre Windows 10 amd64: name old time/op new time/op delta RunningGoProgram-8 17.0ms ± 1% 15.3ms ± 2% -9.71% (p=0.000 n=10+10) This CL is based on CL 22932 by John Starks. Fixes #15588. Change-Id: Ib14be0206544d0d4492ca1f0d91fac968be52241 Reviewed-on: https://go-review.googlesource.com/37915 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> 2016-04-23 21:37:12 -06:00			`FixLongPath = fixLongPath`
			`NewConsoleFile = newConsoleFile`
			`CommandLineToArgv = commandLineToArgv`
os: make readConsole handle its input and output correctly This CL introduces first test for readConsole. And new test discovered couple of problems with readConsole. Console characters consist of multiple bytes each, but byte blocks returned by syscall.ReadFile have no character boundaries. Some multi-byte characters might start at the end of one block, and end at the start of next block. readConsole feeds these blocks to syscall.MultiByteToWideChar to convert them into utf16, but if some multi-byte characters have no ending or starting bytes, the syscall.MultiByteToWideChar might get confused. Current version of syscall.MultiByteToWideChar call will make syscall.MultiByteToWideChar ignore all these not complete multi-byte characters. The CL solves this issue by changing processing from "randomly sized block of bytes at a time" to "one multi-byte character at a time". New readConsole code calls syscall.ReadFile to get 1 byte first. Then it feeds this byte to syscall.MultiByteToWideChar. The new syscall.MultiByteToWideChar call uses MB_ERR_INVALID_CHARS flag to make syscall.MultiByteToWideChar return error if input is not complete character. If syscall.MultiByteToWideChar returns correspondent error, we read another byte and pass 2 byte buffer into syscall.MultiByteToWideChar, and so on until success. Old readConsole code would also sometimes return no data if user buffer was smaller then uint16 size, which would confuse callers that supply 1 byte buffer. This CL fixes that problem too. Fixes #17097 Change-Id: I88136cdf6a7bf3aed5fbb9ad2c759b6c0304ce30 Reviewed-on: https://go-review.googlesource.com/29493 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> 2016-09-20 19:19:36 -06:00			`)`