This is awesome, I am going to divide by linux in my code everywhere in an attempt to obfuscate what I am doing.
Edit: Or /.*BSD/. :-(
11–20 of 60 posts
This is awesome, I am going to divide by linux in my code everywhere in an attempt to obfuscate what I am doing.
Edit: Or /.*BSD/. :-(
When I see a lowercase symbol used as a variable, I expect it's going to be some actual global variable. When I see a lower case symbol used like a function I expect it's an actual function. And then comes the day I want to take the address of the "function" and it fails. Or worse, I make a syntax error somewhere and because of the macro expansion it gives me the most perplexing error message in the world and it takes me 5 minutes and digging through 4 levels of include files to realize I forgot a colon or something.
Not to mention the mess if the macro is poorly implemented and does things like using a parameter several times which causes hard to catch undefined behaviours in the application. Nothing worse than having a seemingly harmless code like "foo(a++)" turn into the bug of doom because you didn't know foo was a macro. Please don't do that.
On the other end when I get a weird behaviour/error message around a capitalized symbol I automatically think that it must be a macro and go dig for the definition.
Just a note: This was on the stackoverflow weekly newsletter yesterday. If you're interested in more questions like this it's worth to check it out, I like it a lot.
PS: That's one of the few reddit customs I really like "link for the lazy" :)
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 looked at the preprocessor output.
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.
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 looked at the preprocessor output.
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'…
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;
}Earlier quoted context omitted.
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'…
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; }
Earlier quoted context omitted.
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; }
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.
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.