Macro abuse



  • This comes from an award winning piece of software made by an internationally reknowned company. This macro is embedded liberally throughout their framework code and examples:

     

    // Description:
    // Try an operation. If fails, return the error code.
    // Arguments:
    // expr - The operation to try.
    #define CUSTOM_TRY(expr) \
        OurResut tryResult = expr; \
        if (tryResult != RESULT_NO_ERROR) \
            return tryResult; \


  • I don't see the problem. There is the potential for duplicate variable declarations, but other than that, nothing.



  • @henke37 said:

    I don't see the problem. There is the potential for duplicate variable declarations, but other than that, nothing.

    How about calling 'return' from inside a macro?
    That seems a little weird to me.

    Or maybe it's spelling renowned with a k? :-p



  • What the heck is "award winning" software?

    What award is that?  Best song?  Best actor?  Best use of pointers?

     



  • @henke37 said:

    I don't see the problem. There is the potential for duplicate variable declarations, but other than that, nothing.

    There is no ON ERROR RESUME NEXT, that's the problem



  • @El_Heffe said:

    What the heck is "award winning" software?

    Awards are a proven method to evaluate the value of an application.



  • @Speakerphone Dude said:

    @El_Heffe said:

    What the heck is "award winning" software?

    Awards are a proven method to evaluate the value of an application.

     Except when in front of congress.



  • @Speakerphone Dude said:

    @henke37 said:
    I don't see the problem. There is the potential for duplicate variable declarations, but other than that, nothing.

    There is no ON ERROR RESUME NEXT, that's the problem

    But this code does the same thing. More or less.



  • FreeBSD TCP stack is full of that shit.



  • Ok, so my spelling of "renowned" leaves somthing to be desired.

     As for "award winning" - I can't tell you what package this came from, and telling you WHICH award it won would cause all sorts of problems.

    The problem with this macro was that it hid a return statement, thus making program flow a total nightmare to follow. Because the argument called was typically a function which had planty of CUSTOM_TRY macros in it it also meant that the documented return values were, by and large, full of crap too.



  • @arkadye said:

    The problem with this macro was that it hid a return statement, thus making program flow a total nightmare to follow. Because the argument called was typically a function which had planty of CUSTOM_TRY macros in it it also meant that the documented return values were, by and large, full of crap too.

     

    I'm sure it has won the award for obstructing reverse engineering. Were you meant to debug it in the first place? I mean, you buy award winning software, then you should get award winning support. Right?



  • Ooh, is this software "best in class" too?



  • @arkadye said:

    Ok, so my spelling of "renowned" leaves somthing to be desired.

    "Reknowned" means that they used to be known, and then we forgot all about them, and now their name pops up in the news again. Sort of like Atari. Much like Mitt Romney. Nice word, arkadye; thanks.

    @arkadye said:

    The problem with this macro was that it hid a return statement, thus making program flow a total nightmare to follow.

    Agree totall

    @arkadye said:

    Because the argument called was typically a function which had planty of CUSTOM_TRY macros in it it also meant that the documented return values were, by and large, full of crap too.

    Another good word - "planty". You plant these things in your code, planty of them, and you get planty of bugs. Thanks again. You're a word inventor!

    As for return values, that depends on the specifications. I have quite a few situations where the return values are "empty string = worked OK, non-empty string = error message". Or you could return 0 for OK and any standard Unix error code for not OK. As long as the return value specification is open-ended, it's a reasonable programming technique to simply return an error code that you received from a sub-function call.

    But yes, a return embedded in a macro is ugly.

     



  • They should put {} avoiding duplicate



  • @El_Heffe said:

    What the heck is "award winning" software?

    What award is that?  Best song?  Best actor?  Best use of pointers?

     

     

    Best use of macros, obviously.

     


  • Discourse touched me in a no-no place

    They should wrap the whole thing in a do{}while(0) so that it doesn't leak syntactic evilness all over the surrounding statements. Aside from that, so long as everyone [i]knows[/i] that it's able to return, it's not that big a deal.

    I've written macros that did computed gotos in C. Now those were truly horrible things...



  • @dkf said:

    ...I've written macros that did computed gotos in C...

    Doesn't it feel better to have that off your chest?



  • Here, have a few: http://codeoffsets.com/


Log in to reply