Skip to content

G
golang
Switch branch/tag
  1. 01 Apr, 2015 3 commits
    • Dave Cheney's avatar
      cmd/go: always link external test packages first when using gccgo · 9d023977
      Dave Cheney authored 
      This CL is an amagamation of several fixes Canonical have made on their
fork of the cmd/go tool (packaged as gccgo-go.deb on Ubuntu 14.04+).

Additionally this CL brings gccgoToolchain.ldi() up to date with the version
that will ship in gccgo-5.0. As gccgo is most likely to be used with its
own version of the go tool that it supples it makes good sense that the libgo
version should dictate the contents of gccgotoolchain.ld()

Please see https://codereview.appspot.com/222890043/ for more details on the
issues fixed.

Change-Id: Icf7deb43f8e80b424757f1673e6bca7a0aa2a1ac
Reviewed-on: https://go-review.googlesource.com/8250Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      9d023977
    • Evan Phoenix's avatar
      text/scanner: Fix EOF reporting on strange Readers · 9c037527
      Evan Phoenix authored 
      Currently, scanner uses -1 to represent 2 different states:

1. I haven't yet scanned anything, call it "Beginning of File"
2. I've reached the end of the input, ie EOF

The result of this behavior is that calling Peek() when next()
has detected the end of the input and set s.ch to scanner.EOF,
is that Peek() things "oh, s.ch is < 0, which to me means that
I haven't scanned any next yet, let me try and clear the BOM
marker."

When this behavior is run on a typical IO, next() will issue
a Read and get (0, io.EOF) back for the second time without
blocking and Peek() will return scanner.EOF.

The bug comes into play when, inside a terminal, hitting Control-D.
This causes the terminal to return a EOF condition to the reader
but it does not actually close the fd.

So, combining these 2 situations, we arrive at the bug:

What is expected: hitting Control-D in a terminal will make Peek()
return scanner.EOF instantly.

What actually happens:

0. Code waiting in Next()
1. User hits Control-D
2. fd returns EOF condition
3. EOF bubbles it's way out to line 249 in scanner.go
4. next() returns scanner.EOF
5. Next() saves the scanner.EOF to s.ch and returns the previous value
6. Peek() runs, sees s.ch < 0, mistakenly thinks it hasn't run yet and
   tries to read the BOM marker.
7. next() sees the buffer is empty and tries to fill it again, blocking
   on line 249.

The fix is simple: use a different code to indicate that no data
has been scanned.

Change-Id: Iee8f4da5881682c4d4c36b93b9bf397ac5798179
Reviewed-on: https://go-review.googlesource.com/7913Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      9c037527
    • Martin Möhrmann's avatar
      fmt: improve test coverage of %x and %X format variations for strings · 15e66f9d
      Martin Möhrmann authored 
      The tests in the basic string section are now covering more code paths
for encoding a string into the hexadecimal representation of its bytes.

Changed the basic string and basic bytes tests so that they mirror each other.

Change-Id: Ib5dc7b33876769965f9aba2ac270040abc4b2451
Reviewed-on: https://go-review.googlesource.com/2611Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
Reviewed-by: 's avatarRob Pike <r@golang.org>
      15e66f9d
  3. 31 Mar, 2015 10 commits
  5. 30 Mar, 2015 16 commits
  7. 29 Mar, 2015 1 commit
  9. 28 Mar, 2015 10 commits