Open sayotte opened 7 years ago
Whether or not the API is a mistake, it's frozen now, as you've noted.
The other possibility is you can pass in an io.Reader wrapper that counts how many bytes have been read through it.
It doesn't seem worth adding more API to the package at this point.
@bradfitz somehow that possibility hadn't occurred to me, guess I'm still getting used to satisfying interfaces.
The workaround will definitely suffice but I still hate the inconsistency. Is there a Wish List of things the Go team would like to get more right in a Go-2.0, if such a thing ever comes to be?
Thanks for the swift response!
The wishlist is issues with the "go2" label.
@ianlancetaylor can we add that label here, rather than closing it as a "let's never fix that"?
@sayotte Done.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?1.7.4
What operating system and processor architecture are you using (
go env
)?linux/amd64 linux/arm darwin/amd64
What did you do?
I want to use
binary.Read()
to marshall data to/from network byte-order. I must keep track of my offset from the beginning of the stream (I'm decoding DNS records, which sometimes refer to strings found at offsets-from-0 farther back as a form of compression). I would prefer not to require the use of anio.ReadSeeker
just for the sake of discovering my current offset.What did you expect to see?
I expected
binary.Read()
to return the number of bytes read, as all of theio.Read
implementations do.What did you see instead?
It doesn't! This seems like a silly oversight, but also not a big or difficult change.
I created a trivial library to replace the function. In retrospect, it would be better to have a differently-named function in the upstream Golang
binary
package so that Go-1.x compatibility isn't broken.binary.Read
could be a wrapper which just drops the bytesRead return value.