Code review - Issue 170750043: code review 170750043: doc/go1.4.html: final library changeshttps://codereview.appspot.com/2014-10-29T22:44:47+00:00rietveld
Message from unknown
2014-10-29T20:36:45+00:00rurn:md5:38733434c596bade3e5f170eeaa5374a
Message from r@golang.org
2014-10-29T20:36:50+00:00rurn:md5:a450d20abed8ee43f4c1ec90a9552fd5
Hello golang-codereviews@googlegroups.com,
I'd like you to review this change to
https://code.google.com/p/go
Message from rsc@golang.org
2014-10-29T21:55:35+00:00rscurn:md5:5d9f7efc6c441ca5c5e378d31e5f917a
LGTM
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html
File doc/go1.4.html (right):
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode564
doc/go1.4.html:564: so the split function can generate a final empty token.
as the documentation has always promised,
or something like that, to make clear this is just doing what was always documented.
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode569
doc/go1.4.html:569: handle empty tokens at EOF as desired.
The most common failure mode for a bad split function is an infinite loop generating empty tokens at EOF. Programs that used to 'work' now hang. I saw this a couple times updating Google code. Should we make the Scanner implementation count empty tokens at EOF and panic if it sees 100 or something like that?
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode716
doc/go1.4.html:716: as it already does for the other systems.
s/does/did/?
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode755
doc/go1.4.html:755: implementations on Linux of
s/.*/implementation on Linux, the/
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode767
doc/go1.4.html:767: func TestMain(m *<a href="/pkg/testing/#M"><code>M</code></a>)
s/M/testing.M/
Message from r@golang.org
2014-10-29T22:34:59+00:00rurn:md5:e9444bc5dab77e73a2294b16490eddd9
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html
File doc/go1.4.html (right):
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode564
doc/go1.4.html:564: so the split function can generate a final empty token.
On 2014/10/29 21:55:34, rsc wrote:
> as the documentation has always promised,
>
> or something like that, to make clear this is just doing what was always
> documented.
>
Done.
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode569
doc/go1.4.html:569: handle empty tokens at EOF as desired.
On 2014/10/29 21:55:34, rsc wrote:
> The most common failure mode for a bad split function is an infinite loop
> generating empty tokens at EOF. Programs that used to 'work' now hang. I saw
> this a couple times updating Google code. Should we make the Scanner
> implementation count empty tokens at EOF and panic if it sees 100 or something
> like that?
https://code.google.com/p/go/issues/detail?id=9020
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode716
doc/go1.4.html:716: as it already does for the other systems.
On 2014/10/29 21:55:34, rsc wrote:
> s/does/did/?
Done.
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode755
doc/go1.4.html:755: implementations on Linux of
On 2014/10/29 21:55:34, rsc wrote:
> s/.*/implementation on Linux, the/
Done.
https://codereview.appspot.com/170750043/diff/1/doc/go1.4.html#newcode767
doc/go1.4.html:767: func TestMain(m *<a href="/pkg/testing/#M"><code>M</code></a>)
On 2014/10/29 21:55:34, rsc wrote:
> s/M/testing.M/
Done.
Message from unknown
2014-10-29T22:35:45+00:00rurn:md5:a0ffbf37c48197c33260c7011fe2cdb1
Message from r@golang.org
2014-10-29T22:35:52+00:00rurn:md5:947a58079c6d8bcd8dd0e088b011f69b
*** Submitted as https://code.google.com/p/go/source/detail?r=3f6f728549d3 ***
doc/go1.4.html: final library changes
First draft now complete.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://codereview.appspot.com/170750043
Message from gobot@golang.org
2014-10-29T22:44:47+00:00goboturn:md5:d41578374ead81b74bb34c8bf2b0edb6
This CL appears to have broken the openbsd-386-rootbsd builder.
See http://build.golang.org/log/59b31cffb4237b8572a3bff1b1aee0b4d994c05c