instead, encode them as, well, bytes.

Example:

    bencode.Marshal(os.Stdout, []byte{'1', '2', '3'})

results in

    li49ei50ei51ee

instead of just

    3:123

Why not just use string? ~~Because in Go, they, by definition, should only contain valid Unicode. bencode "strings" however allow binary data.~~

Edit: okay I just realized this is wrong. Anyway, []byte should be handled the same way!

You can now use the following syntax in a tag struct :

type myStruct struct {
// Ignored during Marshalling
Field string `bencode:"-"` 
// Ignored during Marshalling if empty otherwise named  "name"
Field2 string `bencode:"name,omitempty`
// Ignored during Marshalling if empty otherwise named with default field.Name in this case "Field3"
Field3 string `bencode:",omitempty`
}

In this version, the old tag style is no longer supported.

Note the B/op column.

Before: $ go test -benchmem -bench=. PASS BenchmarkDecodeAll 5000 483495 ns/op 62057 B/op 186 allocs/op BenchmarkUnmarshalAll 5000 788224 ns/op 66498 B/op 291 allocs/op

After $ go test -benchmem -bench=. PASS BenchmarkDecodeAll 10000 277428 ns/op 7681 B/op 160 allocs/op BenchmarkUnmarshalAll 5000 528511 ns/op 12674 B/op 274 allocs/op

I tried to send you this patch list before, but code.google.com doesn't have a nice "pull request" flow..

This change updates the parse function to only wrap the provided reader in a bufio.Reader when it doesn't fulfill the bencode.Reader interface. This allows parsing of a stream of concatenated bencoded messages.

Found by 'go vet'.

After these fixes are applied, some errors remains, not sure how to handle these:

$ go vet
bencode_test.go:231: struct field tag "a" not compatible with reflect.StructTag.Get: bad syntax for struct tag pair
bencode_test.go:237: struct field tag "t" not compatible with reflect.StructTag.Get: bad syntax for struct tag pair
bencode_test.go:238: struct field tag "y" not compatible with reflect.StructTag.Get: bad syntax for struct tag pair
bencode_test.go:239: struct field tag "q" not compatible with reflect.StructTag.Get: bad syntax for struct tag pair
bencode_test.go:240: struct field tag "a" not compatible with reflect.StructTag.Get: bad syntax for struct tag pair
exit status 1

Since the original bencode standard doesn't allow floats, some software have unfortunately decided to bencode floats as integers. This is a stupid idea, because they could've just used a string. But since .torrent files with this feature already exist, we should try to handle them gracefully. This commit allows the parsing of floats & scientific notation, and adds testing for them, casting them to int64 under the following rules: -All floats are rounded to the adjacent integer with the lowest absolute value (7.5 is rounded to 7, while -7.5 is rounded to -7). -Floats that exceed the positive or negative bounds of int64 representation are set as -9223372036854775808.

Unlike the json encoder, this bencode implementation tries to encode unexported struct fields. Would it make sense to change the behavior to ignore such fields? I can work on PR.

I noticed that bencode.Unmarshal() creates a bufio.Reader from the passed-in reader. After bencode.Unmarshal() returns, the passed-in reader is left modified with the new index that the bufio.reader used to fill its buffer. This leaves the caller of bencode.Unmarshal() with a reader that is likely to be at the incorrect index from where the bufio.Reader left off.

Some solutions I can think of off the top of my head:

• Force bencode.Unmarshal() to take in a bufio.Reader not just any io.reader
• Return the bufio.Reader that was created from the passed-in reader (from this point on, you must use only the buffered reader to do all the reads from the underlying reader)

From BitTorrent's BEP 3, we need to calculate a hash of the info value (itself a bencoded dict) from a .torrent file:

Note that this is a substring of the metainfo file. The info-hash must be the hash of the encoded form as found in the .torrent file, which is identical to bdecoding the metainfo file, extracting the info dictionary and encoding it if and only if the bdecoder fully validated the input (e.g. key ordering, absence of leading zeros). Conversely that means clients must either reject invalid metainfo files or extract the substring directly. They must not perform a decode-encode roundtrip on invalid data.

Because info has optional fields like private, it's impossible to predictably unmarshal/marshal it to calculate the hash. It would be nice if there were a way to access the raw bytes of a bencoded value.

When the data contains a large string length as in the example below, decodeString tries to allocate all of this memory upfront so the program crashes.

package main

import (
	"bytes"
	"fmt"

	"github.com/jackpal/bencode-go"
)

func main() {
	data := []byte("99999999999:")
	buf := bytes.NewBuffer(data)
	res, err := bencode.Decode(buf)
	fmt.Println(res, err)
}