#define continue break

  #define break

For example, we could force a double-valued transcendental function to float and back for a small loss of precision in normal cases:

    #define sin(d) ((double)sinf(d))

    double i =  10
    --> i    =  10.0000000000
    sin(i)   = -0.5440211109
    sinf(i)  = -0.5440211296
    delta    =  0.0000000187
    
    double i =  0.25
    --> i    =  0.2500000000
    sin(i)   =  0.2474039593
    sinf(i)  =  0.2474039644
    delta    = -0.0000000051
    
    double i = 9999999.999999
    --> i    = 9999999.9999989998
    sin(i)   =  0.4205487007
    sinf(i)  =  0.4205478132
    delta    =  0.0000008875

Another idea: Let's say we know the application relies on rand() to produce the correct distribution for testing, or maybe to generate session keys. Changing the semantics of the RNG won't result in a compiler bug, but it might result in the tests failing to cover all cases, or a horrible security breach.

The rest would probably be found quite quickly, but omitting volatiles could lead to hard to detect bugs that will only manifest themselves under specific circumstances.

The only legitimate reasons for using volatile generally involve memory-mapped IO and POSIX signal handlers. C's volatile is nothing like Java's volatile and has very weak semantics. With lock-based code you generally have nothing to worry about because lock/unlock has load-acquire/store-release semantics. But if you're writing lock-free code, volatile is useless in general and you need to think carefully about how atomicity is affected by memory alignment and operand size (e.g. a byte write that might look atomic implicitly turns into a non-atomic read-modify-write), explicit memory barriers, etc.

So defining away volatile won't actually impact most applications unless they're relying on very compiler-specific behavior.

  The values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria:
  · they are local to the function that made the corresponding setjmp(3) call;
  · their values are changed between the calls to setjmp(3) and longjmp(); and
  · they are not declared as volatile.

    // region 1:
    // x is allocated to register r1
    int x = 0; // store 0 to r1
    jmpbuf jb;
    if (setjmp(jb) == 0) {
        // region 2:
        // x is re-allocated to r2, so r1 is copied to r2
        x = 42; // store 42 to r2
        longjmp(jb, 1);
    }
    // region 3:
    // x is allocated to r1
    printf("%d\n", x); // load from r1

Actually, this would still occur even if x was always allocated to r1. The reason is that before calling setjmp() the compiler spills x to the stack, so the callee can use the registers for its own use, and on returning (either via longjmp() or the first time through) it will restore x from the value on the stack.

I tried the example above with GCC. At the default optimization level it printed 42. But with -O2 it printed 0. Looking at the assembly code, it's actually even worse than I described. The compiler has treated the longjmp() akin to an exit() and so has determined that the x = 42 is actually a no-op that can be eliminated. This is similar to how in printf("1"); exit(0); printf("2"); the compiler will actually remove the second printf() as dead code from the executable.

So, in conclusion, there seems to be a whole bunch of ways in which the compiler could screw this up while staying within the bounds of standards-acceptable behavior.

My knowledge of proper usage of volatile in C is weak. Does it have something to do with the fact that sizeof bool < sizeof int on most platforms?

In that case I mentioned, yes, the issue is that sizeof(bool) = 1 by default on most compilers. You can force it to be 4 on MSVC with a compiler directive but that has its own problems (e.g. you are using a library which uses bools in its API and the library was compiled with sizeof(bool) = 1). The solution is to never use bool, int, etc, directly for variables that will be written to in lock-free code. Use typedefs (or even better for type safety, wrapper structs) that are explicit about size, make all lock-free reads and writes go through library functions/macros that provide the right atomic semantics.

Here's the specific data race with the bools. Assume that sizeof(bool) = 1 and that the two aforementioned bool bytes (call them A and B) wind up next to each other in the same 4-byte aligned word of memory. Thread 1 writes to A and thread 2 writes to B concurrently. It looks like there should be no data race because they're writing to separate variables. But unlike storing a full word to memory, storing a byte involves an implicit read-modify-write, so the only way for this situation to be safe is if thread 1 and 2 use CAS operations to write A and B.

I'm not sure how much you'd have to mark volatile to get a compiler to behave the way you want, so you could use int and dodge the issue. Or better, the standard sigatomic_t type is provided and should work.

I'd personally go with while -> if, that's very sneaky.

    int main(void)
    {
        while (1) break;
        return 0;
    }

    int main(void)
    {
        while (1) {
            char c = getchar();
            if (c == 'q') break;
            process(c);
        }
        return 0;
    }

#define pthread_mutex_lock(x)

#define pthread_mutex_unlock(x)

  #define goto

  myLabel:
  /* some code*/
  goto myLabel;

  myLabel;

    #define free(x)

Problem of course is to find a nice size range for the program at hand.

#define if(x) if(rand()<0.0001 && (x))

that way it will fail extremely rarely and be even harder to detect!

#define malloc(x) malloc(random())

    #define free(x) do { free(x); x = NULL; } while (0)

There's also people doing stupid shit like free(&x), but those people don't need evil macros to dick up their code. :)

While this is C++, I've actually seen this particular construct: delete new SomeClass(...);

used as, basically, an eye-poppingly clever way of initializing something, doing work, and then cleaning up after.

    { SomeClass makeitso; }

Also, free(ptr++) is broken by design, the post increment value is useless. But free(*ptr++) is a good case.

Yes, of course - that's what I thought I'd written. Clearly not :)

And then later it passes that return value to some function that deallocates the block, by calling free(((char *)p) - n).

   #define printf(...) printf(__VA_ARGS__); puts("\n\n\n\nFAIL!")

    __attribute__((constructor)) void __maiin(void)
    {
        if (rand() < 0.05) exit();
        //if (rand() < 0.05) close(1);
        //if (rand() < 0.05) main(); // and so on ..
    }

I did this one to a friend (briefly) during school.

    #define assert(x) ((void)(x))

* asserts are used in a defensive programming style to state invariants

* the enemy developers will be reasoning about the code assuming that asserts which didn't fire were true

* when debugging, they'll read the code and prematurely dismiss valid theories as to why the bug exists based on what they read in the assertions

If the problem was to slow down early development I'd absolutely agree with you.

#define NDEBUG 1

    #define rand() (rand() % 100)

  #define memmove memcpy
  #define default default: break; case 0xfeceface

#define do

You could even slip that into a makefile (-Ddo=) and it might not be noticed.