That #define comment behavior is interesting - I wonder if it was the cause of a nasty bug I had a looooong time ago when I was porting the driver for our Seria

That #define comment behavior is interesting - I wonder if it was the cause of a nasty bug I had a looooong time ago when I was porting the driver for our Serial HIPPI NIC to the initial release of NT 4.0 (NDIS 4). There was a crash bug that happened only every few million packets. Obviously, this was a race condition. After a lot of hair-puling and waiting for 5-30min every time I wanted to test something, I decided to simply replaced the actual locking code with a single global spinlock at every entry to see if a serialized driver worked[1]. After that version still crashed, and a lot of trial and error, I finally found out that the spinlock were never actually running. Microsoft's compiler was compiling loops like this as if it was a NOOP: #define SPINLOCK(lock) \ for (;;) { \ if (TESTLOCK(lock)) \ break; \ } But it worked after I made this change: - for (;;) { + while (1) { Empty for loops were dropped... but only in macros. Now I'm wondering if it was getting commented out in some subtle way. [1] There was some concern about hardware errors, as a similar PCI chip we were using failed to notice changes in the PCI GNT# if it change REQ# in the same clock cycle.