4 ms·

I spent at least an hour a while ago trying to track down a bug that turned out to be caused by exactly this. I couldn't work out what was happening until I lo

• twoodfin 13y ago
  I'm increasingly turning to -E to debug these hard-to-understand problems. I'd love a -E2 or what-have-you that would be even more verbose, and list all preprocess transformations applied to a line and the source lines where they were defined. Unfortunately, the standard preprocessor output doesn't provide a convenient way to do this without a comment format. I guess you could use a do-nothing #pragma. Eventually, I'm sure somebody will spin up some extension to clang to show you the complete evolution of a block of code and what other code contributed to that evolution.
  • simias 13y ago
    Emacs has a "c-macro-expand" function which is quite hackish but extremely useful, IMO: it attempts to macro expand the region. For instance running it on the following code in the middle of a C source file: #define BOGO_MAX(a, b) a > b ? a : b int test() { return BOGO_MAX(3 + 4, 5); } Creates a new buffer containing: int test() { return 3 + 4 > 5 ? 3 + 4: 5; }
    • tedunangst 13y ago
      How well does that play with ifdef? The problem is rarely what does this macro expand to, but which macro is going to be expanded.
      • simias 13y ago
        Well, I guess it depends on what your code looks like. That being said if I'm not sure if some code is being compiled I just add an "#error foo" and rebuild. Or even simpler I just type in some garbage to trigger a compilation error.