Endiana Jones and The Last Crash-ade

This is a discussion on Endiana Jones and The Last Crash-ade within the C Programming forums, part of the General Programming Boards category; (Apologies for the title, ran out of ideas ) Hello, I'm looking at making a program I'm working on endian-independant. ...

  1. #1
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,262

    Exclamation Endiana Jones and The Last Crash-ade

    (Apologies for the title, ran out of ideas )

    Hello,

    I'm looking at making a program I'm working on endian-independant. Looking through the search results, the general consensus suggests testing a pointer, but I find that a bit... wasteful.

    Think about it: you're compiling the program to run on one specific platform (This isn't Java, and that does everything in big-endian anyway), so rather than actually checking how the platform deals with numbers every time it's run, isn't there some sort of preprocessor definition that would allow me to melt away conversion function calls on platforms that don't need them?

    I originally thought that there would be a preprocessor definition you could test for to find out the target platform. So much for good ideas, eh?

  2. #2
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,163
    How about something like:
    Code:
    itsme@dreams:~/C$ cat endiantest.c
    #include <stdio.h>
    #include <netinet/in.h>
    
    #define IS_BIG_ENDIAN (0x12345678 == htonl(0x12345678))
    
    int main(void)
    {
      printf("This is a %s endian machine.\n", IS_BIG_ENDIAN?"big":"little");
    
      return 0;
    }
    On my spiffy little Intel box I get:
    Code:
    itsme@dreams:~/C$ ./endiantest
    This is a little endian machine.
    If you understand what you're doing, you're not learning anything.

  3. #3
    Registered User
    Join Date
    Aug 2002
    Location
    Hermosa Beach, CA
    Posts
    446
    What do you mean by endian-independent? Do you have a networked application and you want it to work if the client is big-endian and the server is little endian? Have you looked at using the standard conversion macros, i.e. htonl, htons, ntohl, ntohs?

    In general the 'h' stands for host and the 'n' stands for network, so you can read the macros as "htonl: host to network long", "htons: host to network short", etc. Host is whatever the native platform byte-order is, network-byte-order is always big-endian.

    So, on a SUN machine (big-endian) htonl is a no-op, while on a windows little-endian machine, it will convert a 32-bit number from big endian to little endian format.

    So when you are packing your data structures to send, you call either htons or htonl, and when you are unpacking your data structures in the receiving code, you call ntohs or ntohl.
    The crows maintain that a single crow could destroy the heavens. Doubtless this is so. But it proves nothing against the heavens, for the heavens signify simply: the impossibility of crows.

  4. #4
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,262
    It's not a network app, so I don't see the necessity in having to include the sockets library just to get htonl and htons. I've got my own functions to do that job (Which amount to a few bit shifts).

    I mean, I'll do it if it's the only way, but isn't there anything else?

  5. #5
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote Originally Posted by SMurf
    It's not a network app
    So you're storing integers or floats in a file? Why not use text?
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  6. #6
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,163
    Quote Originally Posted by SMurf
    It's not a network app, so I don't see the necessity in having to include the sockets library just to get htonl and htons. I've got my own functions to do that job (Which amount to a few bit shifts).

    I mean, I'll do it if it's the only way, but isn't there anything else?
    And your own functions know whether the host system is big or little endian somehow? Why not use that same method then? See, on big endian machines all those htonl()-ish functions really do nothing at all. They only do something on little endian machines. So if your functions already can tell what type of architecture it is then I don't understand the point of this thread.

    I used htonl() because it will do different things on different architectures in just the right way for you.

    And also, at least on my system, there is no additional library that needs to be added. All you have to do is #include the header file. I don't know if gcc silently adds -lnet to the compile line or if those network functions are tucked away in libc, but I don't have to explicitly link in another library.
    Last edited by itsme86; 03-09-2005 at 03:01 PM.
    If you understand what you're doing, you're not learning anything.

  7. #7
    Registered /usr
    Join Date
    Aug 2001
    Location
    Newport, South Wales, UK
    Posts
    1,262
    Quote Originally Posted by Dave_Sinkula
    So you're storing integers or floats in a file? Why not use text?
    I'm not storing them in a file, other people are. It's a sort of paint program. Nothing like the GIMP, but it's mine...

    And no, my functions don't know the endianness of the host system (The reason why this topic exists!). For now I'm assuming that the host is an x86 (Like my computer, funnily enough) and thus those functions do something while reading most file formats.

    Also, if I remember correctly htonl and htons are stored in the Winsock DLL under Win32 and linked accordingly. I'd like to avoid that if possible.

  8. #8
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Why bother at all then? Save everything a byte at a time, using a format that you come up with. Need RGB sets? Fine, save the first byte for R, the second for G, the third for B, or whatever. Your image format shouldn't care what endian anyone who uses it is.

    Quzah.
    Hope is the first step on the road to disappointment.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21