FAQ
For partly pedagogical reasons, I'm trying to write a program which, in C
style, takes as input a sequence of large integers and uses type assertion
to cast them into a struct of many small members.

Here is a trivial example, where a uint32 becomes a struct with four uint8
members:

http://play.golang.org/p/9OrxXNviMv (can't actually run in the playground
due to import of unsafe).

This is the output on my machine, compiled with gc in go 1.1-rc1
0xfeab0504
A: 0x4
B: 0x5
C: 0xab
D: 0xfe
Num after incrementing 'a' member: 0xfeab0505
unsafe.Pointer makes this as straightforward as, and more concise than,
(void *) tricks in C.

I want to know to what extent - even within one Go implementation - I can
rely on the byte ordering of structs. It looks like the least significant
bits of the number are associated with the members that are listed first in
the struct definition.

Seeing as the language spec (rightly) says little about byte ordering or
endianness, I'm worried that the compiler might flip this around one day on
a whim; in reality I'll be casting uint64 values into structs with members
of a few different types.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jesse McNelis at May 5, 2013 at 7:55 am

    On 05/05/2013 5:20 PM, "Daniel Bryan" wrote:
    Seeing as the language spec (rightly) says little about byte ordering or
    endianness, I'm worried that the compiler might flip this around one day on
    a whim; in reality I'll be casting uint64 values into structs with members
    of a few different types.

    That's why the package is called 'unsafe' because you can't rely on it not
    to change or to be implementation independent.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at May 5, 2013 at 7:58 am

    On Sun, May 5, 2013 at 3:20 PM, Daniel Bryan wrote:

    For partly pedagogical reasons, I'm trying to write a program which, in C
    style, takes as input a sequence of large integers and uses type assertion
    to cast them into a struct of many small members.

    Here is a trivial example, where a uint32 becomes a struct with four uint8
    members:

    http://play.golang.org/p/9OrxXNviMv (can't actually run in the playground
    due to import of unsafe).

    This is the output on my machine, compiled with gc in go 1.1-rc1
    0xfeab0504
    A: 0x4
    B: 0x5
    C: 0xab
    D: 0xfe
    Num after incrementing 'a' member: 0xfeab0505
    unsafe.Pointer makes this as straightforward as, and more concise than,
    (void *) tricks in C.

    I want to know to what extent - even within one Go implementation - I can
    rely on the byte ordering of structs. It looks like the least significant
    bits of the number are associated with the members that are listed first in
    the struct definition.

    Seeing as the language spec (rightly) says little about byte ordering or
    endianness, I'm worried that the compiler might flip this around one day on
    a whim; in reality I'll be casting uint64 values into structs with members
    of a few different types.
    because the endianness is a property of the machine, and Go can't control
    it.

    Go will guarantee that a structure is laid out in the source order
    according the
    proper alignment rules, but please note that alignment of uint8 is only
    specified to be greater
    than or equal to 1, see
    http://golang.org/ref/spec#Size_and_alignment_guarantees,
    so your approach is not portable and unsafe (you probably know this when
    you import
    the "unsafe" package).

    What you should do is using arithmetic operations to split the uint32 apart
    into 4 uint8s,
    then you will control the ordering and endianness.
    like this: http://play.golang.org/p/BMsR3geqBS

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ingo Oeser at May 5, 2013 at 3:30 pm

    On Sunday, May 5, 2013 9:20:13 AM UTC+2, Daniel Bryan wrote:

    I want to know to what extent - even within one Go implementation - I can
    rely on the byte ordering of structs. It looks like the least significant
    bits of the number are associated with the members that are listed first in
    the struct definition.
    The proper answer is: "Don't [rely on byte ordering for anything leaving
    the private memory of your program]!"
    Reasons are explained here:
    http://commandcenter.blogspot.de/2012/04/byte-order-fallacy.html

    I used package encoding/binary to transform your example with 32 bit
    variables here: http://play.golang.org/p/qR8VT9DSd0.
    Since you usually need to know these ordering thingies only for
    communication, the read/writes do not matter in practise,
    as they will most of the time happen anywhere in your stack at some time.


    Seeing as the language spec (rightly) says little about byte ordering or
    endianness, I'm worried that the compiler might flip this around one day on
    a whim; in reality I'll be casting uint64 values into structs with members
    of a few different types.
    Just look at the encoding/binary package after reading the blog article
    above. Byte order is simply not an issue one needs to consider, if coding a
    bit differently at certain places.
    The package encoding/binary makes those places very visible and easy to
    handle.


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Daniel Bryan at May 6, 2013 at 10:45 am
    Thanks for the tip. Pike's logic seems inarguable.

    Hadn't realised the usefulness of encoding/binary. Cheers.
    On Monday, May 6, 2013 1:30:41 AM UTC+10, Ingo Oeser wrote:
    On Sunday, May 5, 2013 9:20:13 AM UTC+2, Daniel Bryan wrote:

    I want to know to what extent - even within one Go implementation - I can
    rely on the byte ordering of structs. It looks like the least significant
    bits of the number are associated with the members that are listed first in
    the struct definition.
    The proper answer is: "Don't [rely on byte ordering for anything leaving
    the private memory of your program]!"
    Reasons are explained here:
    http://commandcenter.blogspot.de/2012/04/byte-order-fallacy.html

    I used package encoding/binary to transform your example with 32 bit
    variables here: http://play.golang.org/p/qR8VT9DSd0.
    Since you usually need to know these ordering thingies only for
    communication, the read/writes do not matter in practise,
    as they will most of the time happen anywhere in your stack at some time.


    Seeing as the language spec (rightly) says little about byte ordering or
    endianness, I'm worried that the compiler might flip this around one day on
    a whim; in reality I'll be casting uint64 values into structs with members
    of a few different types.
    Just look at the encoding/binary package after reading the blog article
    above. Byte order is simply not an issue one needs to consider, if coding a
    bit differently at certain places.
    The package encoding/binary makes those places very visible and easy to
    handle.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Rigby at May 10, 2013 at 5:23 pm
    This is completely off topic but wanted to ask the question about devices
    with one byte order on different endian hosts. For example chip vendors
    will often put the same device in a big endian SOC and a little endian one.
      The device has weird constraints that require it be accessed with 32 bit
    loads and stores only. One SOC is a big endian PPC another is a little
    endian ARM. The hw interface does not do swapping for you so on one
    machine the bytes will be reversed from the other. The Linux kernel deals
    with this by having io accessors that do swapping or not depending on the
    host byte order. I really do not see a way of dealing with this without
    the swapping.

    --john

    On Mon, May 6, 2013 at 4:45 AM, Daniel Bryan wrote:

    Thanks for the tip. Pike's logic seems inarguable.

    Hadn't realised the usefulness of encoding/binary. Cheers.

    On Monday, May 6, 2013 1:30:41 AM UTC+10, Ingo Oeser wrote:
    On Sunday, May 5, 2013 9:20:13 AM UTC+2, Daniel Bryan wrote:

    I want to know to what extent - even within one Go implementation - I
    can rely on the byte ordering of structs. It looks like the least
    significant bits of the number are associated with the members that are
    listed first in the struct definition.
    The proper answer is: "Don't [rely on byte ordering for anything leaving
    the private memory of your program]!"
    Reasons are explained here: http://commandcenter.**
    blogspot.de/2012/04/byte-**order-fallacy.html<http://commandcenter.blogspot.de/2012/04/byte-order-fallacy.html>

    I used package encoding/binary to transform your example with 32 bit
    variables here: http://play.golang.org/**p/qR8VT9DSd0<http://play.golang.org/p/qR8VT9DSd0>
    .
    Since you usually need to know these ordering thingies only for
    communication, the read/writes do not matter in practise,
    as they will most of the time happen anywhere in your stack at some time.


    Seeing as the language spec (rightly) says little about byte ordering or
    endianness, I'm worried that the compiler might flip this around one day on
    a whim; in reality I'll be casting uint64 values into structs with members
    of a few different types.
    Just look at the encoding/binary package after reading the blog article
    above. Byte order is simply not an issue one needs to consider, if coding a
    bit differently at certain places.
    The package encoding/binary makes those places very visible and easy to
    handle.


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at May 10, 2013 at 5:37 pm
    Rob'otic reply:
    http://commandcenter.blogspot.de/2012/04/byte-order-fallacy.html?m=1

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Rigby at May 10, 2013 at 7:31 pm

    On Fri, May 10, 2013 at 11:37 AM, Jan Mercl wrote:

    Rob'otic reply:
    http://commandcenter.blogspot.de/2012/04/byte-order-fallacy.html?m=1

    -j
    I read that and the assumption that one can access anything as an array of
    bytes is what bothered me. There is real hw on real computers that must
    accessed with 32 or 16 or whatever bit width loads and stores. But it just
    now dawned on me that in those cases that one can read then access the
    quantity as a byte array with a union or pointer and assemble it into a
    correctly ordered value dependiing on the devices byte order. So I guess I
    can live with the idea that you never need to consider the hosts byte
    order. So sorry for the noise:)

    --john

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at May 10, 2013 at 8:21 pm

    On 5/10/2013 12:31 PM, John Rigby wrote:
    On Fri, May 10, 2013 at 11:37 AM, Jan Mercl wrote:

    Rob'otic reply:
    http://commandcenter.blogspot.de/2012/04/byte-order-fallacy.html?m=1

    -j
    I read that and the assumption that one can access anything as an array of
    bytes is what bothered me. There is real hw on real computers that must
    accessed with 32 or 16 or whatever bit width loads and stores. But it just
    now dawned on me that in those cases that one can read then access the
    quantity as a byte array with a union or pointer and assemble it into a
    correctly ordered value depending on the devices byte order. So I guess I
    can live with the idea that you never need to consider the hosts byte
    order.
        Go doesn't have unions, for one thing. But then, it's not a low
    level language where you're likely to be dealing with device registers
    and interrupts directly. The Go port to raw hardware
    ("http://code.google.com/p/tinygo/") is a dead project.

          John Nagle



    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 5, '13 at 7:20a
activeMay 10, '13 at 8:21p
posts9
users7
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase