A question about endian-ness turns out to be the wrong question


Via a customer liaison, we received what seemed like a simple question: "How can I detect whether a Windows machine is big-endian or little-endian?"

You could actually answer this question (say by coughing up a code fragment that stores a 16-bit value to memory and then takes it apart into bytes to see how it got stored, or by simply hard-coding it based on the target architecture you are compiling for), but you'd be making the mistake of answering the question instead of solving the problem.

The customer liaison explained, "My customer is having a problem that is caused by a bug in the SAP BI connector. According to the Knowledge Base article, the problem occurs when the SAP BI server is installed on a big-endian system."

Okay, with that background, we immediately recognize that the question is wrong. The problem occurs when the SAP BI server is running on a big-endian system. It doesn't matter what the endian-ness of the Windows machine is, so any mechanism for detecting whether the Windows machine is big-endian or little-endian is barking up the wrong tree.

But it turns out that the customer never even had to do this detection at all. If you read the Knowledge Base article, it says that the problem is already fixed.

The fix for this issue was first released in Cumulative Update 4 for SQL Server 2008 Service Pack 1.

So just make sure you're running Cumulative Update 4 for SQL Server 2008 Service Pack 1 or higher (which, if you've been making any attempt at keeping your server up to date, you've been doing for three years), and the problem will go away.

The customer liaison thanked us for our assistance, but nevertheless asked for the code that would detect the endian-ness of the Windows system. I asked, "How will that help you solve your problem?" but before the customer liaison answered, some other people just gave the customer code that detects the machine endian-ness.

Even though that will do absolutely nothing to solve the customer's problem.

That was the last we heard from the customer liaison. I'm hoping that they actually installed the service pack and solved their problem. And I'm afraid what they're going to do with that code fragment.

Comments (29)
  1. Mikki says:

    People use the opportunity of an occuring problem to learn something new. So when you just tell him: "Use the latest Patch, fool!", the guy did not learn one new thing.

  2. Jonathan says:

    That was the last we heard from the customer liaison

    That makes me think of an explosion in the horizon as the customer deploys the irrelevant Endianess-detection code where it doesn't belong.

  3. kog999 says:

    @Mikki,

    It's more likly the customer liason was focused on answering the customers question and not the customers problem. I doubt it was about learning something new.

  4. MItaly says:

    For a while you had me wondering since when Windows ran on big-endian machines.

  5. The next question from this customer liason was "How can I tell if the Windows machine is using binary arithmetic or trinary?"

  6. Maurits says:

    #include <stdio.h>

    union endianness {

    ____ unsigned char uc[4];

    ____ unsigned int ui;

    };

    int main() {

    ____ if (sizeof(unsigned int) != 4 || sizeof(endianness) != 4) {

    ____ ____ printf("unexpected sizen");

    ____ ____ return -1;

    ____ }

    ____ endianness e = {};

    ____ e.ui = 0xAABBCCDD;

    ____ printf("e.uc = %02x %02x %02x %02xn", e.uc[0], e.uc[1], e.uc[2], e.uc[3]);

    ____ return 0;

    }

    Output on my computer:

    e.uc = dd cc bb aa

    So, little-endian.

  7. metafonzie says:

    @Maurits, That program  helps you determine if your system is little-endian only if you already knew what the term means and were able to mentally parse the output :P

  8. Dorin says:

    So… managers don't really like you, do they? :D

  9. Did Windows ever run on any big-endian hardware ?  I thought it was all little-endian. x86 x64 and Alpha are all little-endian. IA64, MIPS and PowerPC can use either endianness, but I think Windows always uses little-endian.

  10. ulric says:

    who's the bozo that gave the customer code for that.. there are no system except the Xbox where windows isn't running little endian

  11. Cesar says:

    @Nikolas Gloy: There is also ARM, which AFAIK can also be either endian, but most people seem to use in little-endian mode. I do not know which mode Windows uses, but I can guess it uses little-endian there too, like everybody else does.

  12. Maurits says:

    Not strictly Windows, but Apple's Mac OS 9 ran big endian on PowerPC, so Microsoft Office had to compile both ways.

  13. chentiangemalc says:

    Re Mikki: Yes the customer learnt something. When troubleshooting don't make up random solutions until you understand the root cause. Which they didn't. They also learnt they should read the knowledge base more carefully endian-ness problem relates to the "SAP BI Server" is running on, and in future they don't take to take this into consideration for the Windows machine …

  14. MItaly says:

    @Maurits: actually, type-punning via unions is not guaranteed by the standard (although I have yet to see a compiler that doesn't allow it); still, it's more portable (and also more compact) just to do a memcpy from an integer to an array of chars:

    unsigned int i=1;

    char buf[sizeof(i)];

    memcpy(buf, &i, sizeof(i));

    if(buf[0])

       puts("Little-endian");

    else if(buf[sizeof(i)-1])

       puts("Big-endian");

    else

       puts("May God have mercy of your soul.")

    (actually, a more through check would compare all the bytes of buf against the known pattern for big-endian and little-endian, but there's a limit to paranoia against mixed-endian architectures)

  15. MItaly says:

    Unrelated: from the full five stars we can see that xpclient has gone on holiday in an Internet-free location.

  16. Voo says:

    @Matteo: True, though you can also do the following:

    int i = 1;

    char *ptr = (char*)i;

    bool little_endian = *ptr; // MSVC gives a "performance warning" here, so use "*ptr == 1"; although obviously paranoid people can check for mixed endian, etc.

  17. Ross Bemrose says:

    That's one thing that bugs me on StackOverflow (and StackExchange sites in general).  Simple answers to questions tend to get the upvotes, while the more thought-out attempts to address the actual issue tend not to be.

  18. Matt says:

    Customer: "Is my machine running little endian or big endian?"

    My response: "Yes".

  19. JM says:

    @Matt: you say that as if little endian and big endian are the only options. Regrettably, they're not — although I'm pretty sure Windows has never been ported to a middle-endian architecture.

  20. What on Earth would you even do given that the server was Big or Little-Endian?  Just install the update!!!

    I'm not even sure why they were wondering how to detect if the system was big or little endian… it's actually quite trivial to check.  Maybe they checked it themselves, were unable to get the answer they were after (because the question was wrong in the first place) and then decided to double-check by asking MS.

  21. Matt says:

    @JM: All versions of Windows run on either a Little endian architecture or a big-endian one (or both, such as ARM).

  22. I seem to recall Raymond answering the similar question of "how do I tell at runtime if my 64 bit app is running on 64 bit Windows?" (Answer: It is. On anything other than a 64 bit system, it won't run at all!); with the possible corner case of the Xbox 360, it seems "how do I tell if my Windows application is on a little-endian machine?" is another "yes, it is". I can't imagine too many Xboxes connect to SAP servers directly.

  23. Burak KALAYCI says:

    what seemed like a simple question

    Obviously answering that simple question (on any system) in a bug free way is not trivial as it seems: the bug with the connector production code is not being able to detect this correctly.

    Also it makes me wonder how such a bug survives testing, or if any were done at all.

  24. Joshua says:

    @Matteo Italia: I agree. PDP has no mercy.

    @Burak KALAYCI: I refer the honourable gentleman to the solution in the article.

  25. Cheong says:

    I know that they should have installed the Cumulative update, but there's some MIS that I know refrain from install patches to their system, fearing it'll break their programs. Given that they haven't installed something they should have installed 3 years ago, I'm afraid that they'll go to the "code route" if someone said it's possible.

    Don't laugh… at my previous company, we have a client that is a bank still doing UAT for 20+ earlier release of our company's flagship server software… Things are like dead water that won't move forward…

  26. Matt says:

    @jas88: WindowsRT can be big endian.

  27. Steve says:

    Testing the endianess of the server provides the evidence that the patch upgrade is worth the risk to the (otherwise) working system.

    On high reliability standalone (non-internet connected) systems that have been working for years, changing software can be a very arduous (tedious) process, proving to risk averse people responsible that change is necessary.

  28. John Doe says:

    @jas88, "Answer: It is."

    When 32 bit Windows came out, it was the only thing running 32 bit applications. That is, until Win32s and Windows XP x64.

    Who knows until when will it be true that 64 bit applications are only running on a 64 bit Windows? Who knows how can we check for other combinations? Who knows what we might need to do different? Do we need to do anything different?

    [But what would you do if the answer is "You are running on a version of Windows you have never heard of and know nothing about"? -Raymond]

Comments are closed.