I've read that post and I agree. I can only speculate that they designed
the API that way either because of premature optimisation - saving the
underlying binary from potentially having to swap the byte order - or
out of laziness and an assumption that it's easy to read four bytes
into an int in wh
I know the use of native byte order didn't come from you, but that's
lazy and wrong.
https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
-rob
On Thu, Aug 24, 2017 at 12:12 AM, Wojciech S. Czarnecki wrote:
> On Wed, 23 Aug 2017 10:51:25 +0200
> Christian von Kietzell wrote:
>
>>
On Wed, 23 Aug 2017 10:51:25 +0200
Christian von Kietzell wrote:
> [*1] The data comes from a web browser extension using the native
> messaging API, which specifies that messages sent to external programs
> are prefixed with the 32-bit length of the message in native byte order.
I understand th
See https://github.com/tsuna/endian
Tl;Dr use tags to decide which one to use.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegrou
Hi,
I've stumbled across a problem I don't know how to solve.
I'm trying to read (from stdin) four bytes into a uint32 value. Those
bytes are provided in _native_ byte order by an external program.[*1]
Since I've found nothing in the standard library to determine the
machine's native byte order
