Write a program that will produce differing behaviors on as many different platforms as you can. Each differing platform awards one point (including an initial platform, meaning you can't score less than 1*). Mechanisms intended for determining the target/executing platform (e.g. through platform compilation statements or APIs like .NET's Environment.OSVersion.Platform) must not be used. The answer with the highest score wins (where upvotes are the tiebreakers).

For example, consider the following program in the Blub language: print (1+2). If this program were to print 3 on every platform it is compiled and run on, its score would be 1. However, if, for any reason, it were to print 4 on PDP-11s, its score would be 2. Etc. But the following C snippet, for example, is an invalid entry: #ifdef WIN32 ... #endif.


  • Distinct platform: the combination of a) the hardware architecture b) the OS and its MAJOR version number (e.g. 1.0.0 and 1.1.0 are considered the same OS)

  • Differing behavior: two behaviors are the same iff they produce similar side-effects (e.g. creating the same file with the same contents), or if the side-effect are errors of the same kind. For example, if a program segfaults on two distinct platforms, but the segfault message is different on these platforms, this is still considered the same behavior; while a program producing a zero-division error on one platform and a stack overflow (see what I did there? ;) error on another is producing different behavior.

  • All undefined behaviors are considered equivalent.

  • Program must be invoked in an equivalent manner on all platforms (however; this does mean you can pass command-line parameters if you so desire)

* Well, I guess you'd score zero if your program ran on zero platforms. But um... Yeah nevermind.

  • 3
    \$\begingroup\$ Must the program be ran in the same programming language on all platforms? e.g. what if I write a program that prints 1 on Windows and 2 on OSX, with the detail that I run it as a Python script on Windows and a C program on OSX? \$\endgroup\$
    – Lynn
    Jul 29 '15 at 18:17
  • 1
    \$\begingroup\$ @Mauris yes, the program must be run in the same language. Also, come to think of it, they should generally take the same command-line parameters (if any), so you can't just provide different arguments on different platforms. Thanks for the great corner-cases so far guys :) \$\endgroup\$
    – Jwosty
    Jul 29 '15 at 18:19
  • 1
    \$\begingroup\$ Do difference browsers count as different platforms for JavaScript? \$\endgroup\$
    – Downgoat
    Jul 29 '15 at 18:20
  • 4
    \$\begingroup\$ "differing behavior" may need a more precise definition. For example, if a program crashes on multiple platforms, but with different errors, is that differing behavior? \$\endgroup\$ Jul 29 '15 at 18:29
  • 1
    \$\begingroup\$ @mbomb007 I'm sure there are a million APIs that are documented to behave differently on different platforms (which is what I expect most solutions will take advantage of), so answers shouldn't be too hard to verify. As for the ones that are bugs, well, we'll burn that bridge when we come to it. \$\endgroup\$
    – Jwosty
    Jul 29 '15 at 19:45


I will take a stab at it with a textbook-like example:

#include <stdio.h>
#include <stdlib.h>

int main()
    char a[] = {1,2,3,4,5,6,7,8};
    if (sizeof(&a) > sizeof(int)) {
        printf("foo %d %d\n", *(int *)a, *(long *)a);
    } else {
        printf("bar %d %d\n", *(int *)a, *(long *)a);

64-bit Platform prints: foo

32-bit Platform prints: bar

Little Endian Platforms: 67305985

Big Endian Platforms: 16909060

So there is at least 4 combinations.

On top of that, some very old platforms has int defined as 16-bits. And some platform has long defined as 64-bits. So the result will be different as well.

C has been quite platform specific, if you dig deep enough. It is not hard to come up with thousands of combinations (2^10+).

  • 3
    \$\begingroup\$ Isn't this four because of the \n vs \n\r on *nix and windows? \$\endgroup\$
    – Maltysen
    Jul 29 '15 at 20:23
  • \$\begingroup\$ I guess that's true if I divert the output into a file on Linux and read it on Windows. But I don't have a Windows C compiler to confirm that natively. \$\endgroup\$
    – some user
    Jul 29 '15 at 20:29
  • 2
    \$\begingroup\$ printf("\n"); does output \r\n on windows (redirecting stdout to a file on windows resulted in a 2 byte file). \$\endgroup\$
    – es1024
    Jul 29 '15 at 22:54

16/32/64-bit x86/x64 assembly, 16 bytes, 4 combinations


31 C9 41 E2 0A 66 49 41 74 05 0F 00 C0 03 C1 C3

Disassembly (16-bit):

    xor  cx, cx ;cx=0
    inc  cx     ;cx=1
    loop l1     ;fall through
    dec  cx     ;cx=FFFF
    inc  ecx    ;cx=0000
    je   l1     ;branch taken
l1: ret

Disassembly (32-bit):

    xor  ecx, ecx ;ecx=0
    inc  ecx      ;ecx=1
    loop l1       ;fall through
    dec  cx       ;ecx=0000FFFF
    inc  ecx      ;ecx=00010000
    je   l1       ;branch not taken
    sldt ax       ;detect VMware, VirtualPC, Parallels, etc.
    add  ecx, eax ;conditionally modify ecx
l1: ret

Disassembly (64-bit):

    xor   ecx, ecx ;rcx=0 (implicit 64-bit zero-extension)
    loopq l1       ;rcx becomes FFFFFFFFFFFFFFFF, branch taken
l1: ret

It returns:
- CX=0000 in 16-bit mode;
- ECX=10000 in 32-bit non-virtual mode;
- ECX=(random) in 32-bit virtual mode;
- RCX=FFFFFFFFFFFFFFFF in 64-bit mode.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.