Endianness

Discussion in 'C Programming' started by bush, Jun 22, 2005.

  1. bush

    bush Guest

    hi folks
    I am new to this group.i need to know how i can find the endianness of
    my system.help me out.
     
    bush, Jun 22, 2005
    #1
    1. Advertisements

  2. bush

    Eric Sosman Guest

    The best way is not to ask the question in the first place.
    Write code that doesn't care about endianness -- more generally,
    that cares only about the values and not about how they are
    represented.

    Sometimes the best way isn't practical (although IMHO it
    *is* practical far more often than people seem to think). In
    that case, the second-best way to find out is to read your
    system's documentation.

    Sometimes even the second-best way won't do; you might
    need a method suitable for use by the running program. The
    third-best way is to store selected values into an `int' (or
    whatever) and then inspect the individual bytes for clues.
    Be warned: There are more than two possibilities! There are,
    for example, twenty-four ways to arrange the bytes of a four-
    byte `int', and at least three of them have been used in real
    machines.

    The worst way of all is to imagine that you know the answer
    without needing to ask.
     
    Eric Sosman, Jun 22, 2005
    #2
    1. Advertisements

  3. #include <stdio.h>

    int main()
    {
    int n = 0x04030201;
    char *s = (void *)&n;

    printf("%d%d%d%d\n", s[0], s[1], s[2], s[3]);

    return 0;
    }

    This will print '4321' on a big-endian system, like a mac G5 or a SUN
    SPARC. On a pc it will print '1234', meaning it's little-endian. You
    can of course simplify this into only two bytes if you like, it's just
    what I had floating around on my disk. Depends on what you're using it
    for, because then you can't see if it's a 'middle-endian' cpu (on a
    PDP-11 it should print '3412', but those are rare anyway.

    Hope this was what you meant. The clue is to cast the address of an int
    or short to (void *) or (char *), because then it won't get converted
    into the big-endian order when you print it.
     
    Tydr Schnubbis, Jun 22, 2005
    #3
  4. #include <stdio.h>

    int main()
    {
    int n = 0x04030201;
    char *s = (char *)&n;

    printf("%d%d%d%d\n", s[0], s[1], s[2], s[3]);

    return 0;
    }

    This will print '4321' on a big-endian system, like a mac G5 or a SUN
    SPARC. On a pc it will print '1234', meaning it's little-endian. You
    can of course simplify this into only two bytes if you like, it's just
    what I had floating around on my disk. Depends on what you're using it
    for, because then you can't see if it's a 'middle-endian' cpu (on a
    PDP-11 it should print '3412', but those are rare anyway.

    Hope this was what you meant. The clue is to cast the address of an int
    or short to (void *) or (char *), because then it won't get converted
    into the big-endian order when you print it.
     
    Tydr Schnubbis, Jun 22, 2005
    #4
  5. That's fine, if your code is C, and C alone. However, for performance
    reasons, it is sometimes convenient to invoke assembly language functions
    - and then, taking endianness into account matters.
     
    Felix Rawlings, Jun 23, 2005
    #5
  6. bush

    Eric Sosman Guest

    1) I did mention that the strait and narrow way is not
    always practical.

    2) While there are sometimes reasons to stray from the
    strait and narrow, in my experience the need to chit-chat
    with other languages *on the same machine* has not been
    among them. YMMV, of course, but discussions of the unpleasant
    particulars probably belong on system-specific newsgroups.
     
    Eric Sosman, Jun 23, 2005
    #6
  7. Unlikely, at least as far as the C code is concerned. The assembly
    programmer will know the byte order of the architecture and it is rather
    unlikely that the C implementation will use a different byte order to
    this. So if, for example, you pass an int (somehow) to an assembly routine
    you'll end up with a "word", value in a register or whatever in the
    correct byte order for the assembly code to use. There is no need for the
    code to incorporate any explicit knowledge of byte order. When it is
    needed explicitly it is typically the responsibility of the assembly
    code to do the right thing rather than the C code.

    Consider for example that an implementation could implement standard
    library functions in assembly, so your C code might be calling code
    written in assembly without you even being aware of it. It just works as
    far as the C code is concerned.

    Lawrence
     
    Lawrence Kirby, Jun 23, 2005
    #7
  8. (Only) if char is 8 bits, which is true of nearly all platforms
    including those you named but not all and not required by the C
    standard; and there are no embedded or leading padding bits in int,
    again very common but not required.
    Only if you make it 'long'; PDP-11 'int' was 16 bits (2 bytes of 8).


    - David.Thompson1 at worldnet.att.net
     
    Dave Thompson, Jul 4, 2005
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.