6 ms·
I think #define volatile is by far the sneakiest. The rest would probably be found quite quickly, but omitting volatiles could lead to hard to detect bugs that
by wulczer 15y ago
I think #define volatile is by far the sneakiest.
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.
- huhtenberg 15y agovolatile is tied to a fairly specific usage and does not appear in that many projects. I'd personally go with while -> if, that's very sneaky.
- ricree 15y agoI'm rusty on my C preprocessor, but how would this work out for do {} while blocks?
- psykotic 15y agoIt will cause compiler errors, so it's not all that sneaky: int main(void) { while (1) break; return 0; }
- huhtenberg 15y agoIt may rather than will. This ^ is a rather odd, syntax abuse case.
- psykotic 15y agoWhat do you mean? You will get a compiler error in any case where there is a break or continue in an outermost while block. There's nothing odd or uncommon about that. Here's something closer to a real program: int main(void) { while (1) { char c = getchar(); if (c == 'q') break; process(c); } return 0; }
- huhtenberg 15y agoUgh. You are right of course. I had a brain spasm.
- psykotic 15y ago> I think #define volatile is by far the sneakiest. 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.
- tptacek 15y agoIt would definitely be a good way to fuck with kernel code, though.
- psykotic 15y agoThat it would. Lots of raw memory-mapped IO and dependencies on compiler-specific interpretations of C semantics!
- tptacek 15y agoI lost a couple hours of my life to a missing "volatile" writing code to talk to a network processor about 6 years ago, so this is kind of seared into my head.
- psykotic 15y agoYeah, I've done low-level driver and microcontroller code in C as well. But these days I view everything through a multi-threading lens, so my default reaction when I see people bring up volatile is to assume they're talking about its use in threaded code, which is unfortunately commonplace. Yesterday I fixed a latent data race in some lock-free code where a should_kill_thread-style variable had been marked volatile and the author had assumed that was necessary and sufficient to dispel any issues. Incidentally, that variable also had type bool and was in a struct next to another variable of type bool. Ruh roh...