Penned by Joel Sing on 20131119 7:03.47, we have:
| On Tue, 19 Nov 2013, Stuart Henderson wrote:
| > On 2013/11/19 02:38, Brad Smith wrote:
| > > ----- Original message -----
| > >
| > > > On Sat, 2 Nov 2013, Joel Sing wrote:
| > > > > The following diff updates go/lang go 1.2rc3 - this is going to be
| > > > > very close to the final 1.2 release, however we might as well get
| > > > > this in now as it is generally better than the 1.1.1 release and it
| > > > > fixes a regression introduced by the recent route message version
| > > > > change.
| > > > >
| > > > > Passes regress on i386 and amd64, although the API version checks
| > > > > fail (as to be expected).
| > > > >
| > > > > ok?
| > > >
| > > > Anyone? The 1.2rc5 release is now out, which only requires a VERSION
| > > > and checksum update from the below diff. Is there any interest, or do I
| > > > sit on it until 1.2 is released in early December?
| > >
| > > Wait for the 1.2 (final) release.
| >
| > Normally I'd lean towards waiting until final release, but it would be
| > good to have the fixes for bridge/vlan syscalls and route messages sooner,
| > and as it's already been tested this way, it seems to make more sense to
| > me than backporting..
|
| Right, hence my reason for looking at it now rather than later. The 1.2
| release should not be anything more than a version bump and a checksum
| update.
Two more reasons to go with the rc.
1) several memleaks are fixed which make long running apps succeed on i386
whereas
they would fail otherwise (btcd is my use case)
2) there is now code in the rc that is not available in the current ports tree
version
that is relied upon in the wild. For example:
$ go get -u -v github.com/conformal/btcd/...
[..]
github.com/conformal/btcd
# github.com/conformal/btcd
go/src/github.com/conformal/btcd/rpcserver.go:393: undefined:
x509.MarshalECPrivateKey
FWIW.
| > About ParseRoutingMessage, though:
| > : // ParseRoutingMessage parses b as routing messages and returns the
| > : // slice containing the RoutingMessage interfaces.
| > : func ParseRoutingMessage(b []byte) (msgs []RoutingMessage, err error) {
| > : for len(b) >= anyMessageLen {
| > : any := (*anyMessage)(unsafe.Pointer(&b[0]))
| > : + if any.Version == RTM_VERSION - 1 {
| > : + b = b[any.Msglen:]
| > : + continue
| > : + }
| > : if any.Version != RTM_VERSION {
| > : return nil, EINVAL
| > : }
| > : msgs = append(msgs, any.toRoutingMessage(b))
| > : b = b[any.Msglen:]
| > : }
| > : return msgs, nil
| > : }
| >
| > ..shouldn't it skip over routing messages of any incorrect version,
| > rather than just skipping RTM_VERSION - 1 and failing with EINVAL for
| > others? At least, that's the way we handle it in route/netstat etc.
|
| That's a fair question. According to bluhm@, the backwards compatibility
| should soon be removed - my current thinking was to go with the minimal
| workaround that can be reverted later.
|
| There is probably an argument for simply skipping over any unknown routing
| message version, however that then brings up the question of how things
| should behave if we do not know how to handle any of the messages returned
| (i.e. does this mean there are no routing messages, interfaces, etc, or
| should this signal an error condition).
|
| Given that this Go code is shared amongst the BSDs, I'm happy to discuss this
| upstream.
| --
|
| "Action without study is fatal. Study without action is futile."
| -- Mary Ritter Beard
--
Todd Fries .. [email protected]
____________________________________________
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| PO Box 16169, Oklahoma City, OK 73113-2169 \ sip:[email protected]
| "..in support of free software solutions." \ sip:[email protected]
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
