Where is the NDEBUG defined?

Silver Diamond

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?

over 9 years ago

0 George Mock over 9 years ago

TI__Guru**** 249380 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 Silver Diamond over 9 years ago 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 Archaeologist over 9 years ago in reply to George Mock

TI__Guru* 84285 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 Silver Diamond over 9 years ago in reply to Archaeologist

Genius 4010 points

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

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 Silver Diamond over 9 years ago in reply to Archaeologist

Genius 4010 points

By the way, the parenthesis for #if defined are not required.

0 Archaeologist over 9 years ago in reply to Silver Diamond

TI__Guru* 84285 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 Silver Diamond over 9 years ago 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 Archaeologist over 9 years ago in reply to Silver Diamond

TI__Guru* 84285 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 Silver Diamond over 9 years ago 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 Silver Diamond over 9 years ago 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 Archaeologist over 9 years ago in reply to Silver Diamond

TI__Guru* 84285 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 Silver Diamond over 9 years ago in reply to Archaeologist

Genius 4010 points

three lefts require too much code...

Code Composer Studio™︎

Code Composer Studio forum

Where is the NDEBUG defined?