• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 53 subscribers
  • Views 7367 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Where is the NDEBUG defined?

Silver Diamond
Genius 4010 points

Who controls the definition of NDEBUG?  I have the following code snippet:

#if defined NDEBUG
    DebugTX->print("\rPROD");
#endif

No matter what I do, the code inside the #if defined #endif executes.   In Debug build configuration I tried to do the following:

1) Did not Define the NDEBUG - the code inside the #if #endif still rins.

2) Tried to undefine as in the command below:

"/home/sporty/ti/ccsv6/tools/compiler/msp430_15.12.3.LTS/bin/cl430" -vmspx --code_model=large --data_model=large --near_data=none -O2 --opt_for_speed=3 --use_hw_mpy=F5 --include_path="/home/sporty/ti/ccsv6/ccs_base/msp430/include" --include_path="/home/sporty/HydroGuardFW/hw_1_5/miwt_os/include" --include_path="/home/sporty/HydroGuardFW/driverlib_msp430f5335" --include_path="/home/sporty/HydroGuardFW/hw_1_5" --include_path="/home/sporty/ti/ccsv6/tools/compiler/msp430_15.12.3.LTS/include" -g --undefine=NDEBUG --define=__MSP430F5335__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --abi=eabi --printf_support=minimal --preproc_with_compile --preproc_dependency="coap_resources/fw.d" --obj_directory="coap_resources"  "../coap_resources/fw.cpp"

Is there something really special about the NDEBUG?

  • 0
    TI__Guru**** 244710 points

    There is nothing special about NDEBUG.  My guess is some header file is defining it.  Preprocessor problems like this are best debugged by using the option --gen_acp_raw, then inspecting the resulting listing file (file extension .rl).  Please read about it in the MSP430 compiler manual.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4010 points
    Well, you are correct, it is defined in the drivelib's hw_memmap.h, I wonder what is the reason for TI to define it?
  • 0 in reply to George Mock
    TI__Guru* 84225 points
    The C standard specifies the macro NDEBUG, which disables assert statements. The idea is that the user places assert statements in the code for debugging or testing purposes, and then when a build without the testing code is desired, the user will define the macro NDEBUG, perhaps on the command line. This makes it so that the assert statements are not even compiled.

    I'm guessing the author of that project has decided that you would typically only allow assert statements in a Debug environment, and has chosen to define the macro NDEBUG in a production build. This would explain the printed message "PROD." It is probably not relevant that the object containing the print method is named "DebugTX."

    Now, is the text of the #if exactly as you have shown? If so, it is missing parentheses, and should look like this:

    #if defined(NDEBUG)
  • 0 in reply to Archaeologist
    Genius 4010 points

    OK, but the problem is you cannot undefine a define in source code.

    http://stackoverflow.com/questions/1978155/how-to-undefine-a-define-at-commandline-using-gcc

    So no matter what you do, the assert macro is ((void)0), as long as the macro is there.  A band-aid is to comment out that line of code, which works, I tried it, but our policy is not to use modified libraries for production code.  For this reason, I believe that the NDEBUG definition directive makes the behaviour of NDEBUG as nonstandard.

  • 0 in reply to Archaeologist
    Genius 4010 points
    By the way, the parenthesis for #if defined are not required.
  • 0 in reply to Silver Diamond
    TI__Guru* 84225 points

    Silver Diamond said:
    By the way, the parenthesis for #if defined are not required.

    Oop, you're right.  Hm, I've been wrong about the standard twice this week, must be time for a vacation...

  • 0 in reply to Archaeologist
    Genius 4010 points
    Well its one of these MonTuesdays, after an amazing labour day, so should we request TI to remove the drivelib #define NDEBUG line?
  • 0 in reply to Silver Diamond
    TI__Guru* 84225 points
    You said that NDEBUG is defined in drivelib's hw_memmap.h; I'm quite suspicious of that definition. I really don't think it's appropriate for a library's header file to define this macro. It's really intended for command-line usage. I'll have to ask around about that

    You can use #undef to undefine any macro. The command-line defines and undefines are evaluated first, then those in the file in the order they are encountered. I'd suggest adding #undef after the inclusion of the header file:

    #include "hw_memmap.h"
    #undef NDEBUG
  • 0 in reply to Archaeologist
    Genius 4010 points
    I agree that the macro should not be defined by the lib. As far as the #undef NDEBUT macro, is it the right thing to do or is it a band-aid over an issue. I would rather not add lines of code that makes behaviour of a common macro uncommon. For example if someone, working with my code needed to try something in drivelib, they would be confused, so it is best to keep code as close to standard as possible.
  • 0 in reply to Archaeologist
    Genius 4010 points
    Also, I do not include the hw_memmap.h, the drverlib.h is included and through a chain it includes the hw_memmap.h, this is what makes it tough to debug.
  • 0 in reply to Silver Diamond
    TI__Guru* 84225 points
    It's a band-aid, but what else can be done? All I can say is that two wrongs don't make a right, but three lefts do.
  • 0 in reply to Archaeologist
    Genius 4010 points
    three lefts require too much code...