The payload of a data message is defined as an SSH string type,
which uses the first four bytes to encode its length. When channelData
and channelExtendedData were added I defined Payload as []byte to
be able to use it directly without a string to []byte conversion. This
resulted in the length data leaking into the payload data.
This CL fixes the bug, and restores agl's original fast path code.
Additionally, a bug whereby s.lock was not released if a packet arrived
for an invalid channel has been fixed.
Finally, as they were no longer used, I have removed
the channelData and channelExtedendData structs.
R=agl, rsc
CC=golang-dev
https://golang.org/cl/5330053
In the adoption agency algorithm, the formatting element is sometimes
removed from the list of active formatting elements and reinserted at a later index.
In that case, the bookmark showing where it is to be reinserted needs to be moved,
so that its position relative to its neighbors remains the same
(and also so that it doesn't become out of bounds).
Pass tests1.dat, test 70:
<DIV> abc <B> def <I> ghi <P> jkl </B>
| <html>
| <head>
| <body>
| <div>
| " abc "
| <b>
| " def "
| <i>
| " ghi "
| <i>
| <p>
| <b>
| " jkl "
Also pass tests through test 76:
<test attribute---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------->
R=nigeltao
CC=golang-dev
https://golang.org/cl/5322052
Handling os.Error is no different than handling fmt.Stringer
here, so the code is redundant now, but it will be necessary
once error goes in.
Adding it now will make gofix fix it.
R=r
CC=golang-dev
https://golang.org/cl/5331045
alerts get used as both values and errors.
Rather than introduce an alertError wrapper,
this CL just adds an Error method, which will
satisfy the error interface when the time comes.
R=agl, bradfitz
CC=golang-dev
https://golang.org/cl/5294073
It will be obsolete when error happens.
Submitting this now will make the error transition earlier,
at the cost of making a locally-built godoc viewing
/pkg/syscall or /pkg/os have some functions appear
under the Error type as constructors.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/5305067
Will make gofix for error work better.
There is no other indication in this file that
these are actually error implementations.
(They are only used elsewhere.)
R=bradfitz
CC=golang-dev
https://golang.org/cl/5305068
We only guarantee that the main goroutine runs on the
main OS thread for initialization. Programs that wish to
preserve that property for main.main can call runtime.LockOSThread.
This is what programs used to do before we unleashed
goroutines during init, so it is both a simple fix and keeps
existing programs working.
R=iant, r, dave, dvyukov
CC=golang-dev
https://golang.org/cl/5309070
I found these by adding a check to govet, but the check
produces far too many false positives to be useful.
Even so, these few seem worth cleaning up.
R=golang-dev, bradfitz, iant
CC=golang-dev
https://golang.org/cl/5311067
This is true of the existing implementations, and I think
it is an important property to guarantee.
R=golang-dev, r, borman, r
CC=golang-dev
https://golang.org/cl/5321058
goinstall has built in support for a few common code hosting sites. The
identification of which vcs tool should be used was based purely on a
regex match against the provided import path. The problem with this
approach is that it requires distinct import paths for different vcs
tools on the same site.
Since bitbucket has recently starting hosting Git repositories under the
same bitbucket.org/user/project scheme as it already hosts Mercurial
repositories, now would seem a good time to take a more flexible
approach.
We still match the import path against a list of regexes, but now the
match is purely to distinguish the different hosting sites. Once the
site is identified, the specified function is called with the repo and
path matched out of the import string. This function is responsible for
creating the vcsMatch structure that tells us what we need to download
the code.
For github and launchpad, only one vcs tool is currently supported, so
these functions can simply return a vcsMatch structure. For googlecode,
we retain the behaviour of determing the vcs from the import path - but
now it is done by the function instead of the regex. For bitbucket, we
use api.bitbucket.org to find out what sort of repository the specified
import path corresponds to - and then construct the appropriate vcsMatch
structure.
R=golang-dev, adg
CC=golang-dev, rsc
https://golang.org/cl/5306069
Change the name of cas() in cc to newcase() to avoid a NIX conflict.
cas() is used in cc to create a new Case struct. There is a name
conflict in that cas() is a commonly-used
name for compare and swap. Since cas() is only used internally
in the compiler in 3 places, change the name to avoid a wider
conflict with the NIX runtime. This issue might well come up on
other OSes in the future anyway, as the name is fairly common.
R=rsc
CC=golang-dev
https://golang.org/cl/5294071
Small change to go/ast, go/parser, go/printer so that
gofix can delete the blank line left from deleting an import.
R=golang-dev, bradfitz, adg
CC=golang-dev
https://golang.org/cl/5321046
Although there's still no concrete security reason not to use 3, I
think Bleichenbacher has convinced me that it's a useful defense and
it's what everyone else does.
R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5307060
Nothing terribly interesting here. (!)
Since the public APIs are all in terms of UTF-8,
the changes are all internal only.
R=mpvl, gri, r
CC=golang-dev
https://golang.org/cl/5309042
