[DPDK/core Bug 1894] Log library macros pollute the preprocessor namespace

[bugzilla@dpdk.org]

http://bugs.dpdk.org/show_bug.cgi?id=1894

            Bug ID: 1894
           Summary: Log library macros pollute the preprocessor namespace
           Product: DPDK
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: core
          Assignee: dev@dpdk.org
          Reporter: mb@smartsharesystems.com
  Target Milestone: ---

RTE_LOG macros take the severity level parameter without the RTE_LOG prefix,
e.g. RTE_LOG(DEBUG, MEMPOOL, "Something unexpected happened.");

If the application defines a macro named DEBUG, INFO, WARNING, ALERT, or any
other syslog severity name, the application cannot use the RTE_LOG macros, as
the application defined macro will be expanded.

For example:
#define DEBUG 2 /* Debug level. */
RTE_LOG(DEBUG, USER1, "Problem.");

Will first expand the DEBUG definition as:
RTE_LOG(2, USER1, "Problem.");

And then, according to the log library using:
#define RTE_LOG(l, t, ...) \
rte_log(RTE_LOG_ ## l, RTE_LOGTYPE_ ## t, # t ": " __VA_ARGS__)

expand to:
rte_log(RTE_LOG_2, RTE_LOGTYPE_USER1, "USER1: Problem.");

There is no such thing as RTE_LOG_2, so the build will fail.

Changing the RTE_LOG macro to require the full names for severity level and log
type, e.g. RTE_LOG(RTE_LOG_DEBUG, RTE_LOGTYPE_USER1, "Problem."), would fix the
namespace pollution; but it would require updating many source code files.
Backwards compatible macros could be defined in the log library header file
(rte_log.h) for applications still passing the non-prefixed names, e.g.:
#define DEBUG RTE_LOG_DEBUG

As an alternative workaround, the log library header file could define all the
shorthand (prefix stripped) names for log severity level and log type, so the
preprocessor emits a warning if the application also defines any macro with one
of those names.
E.g., in rte_log.h:
#define DEBUG DEBUG
#define USER1 USER1

For this workaround, we would also have to do something similar for the log
types defined in all libraries, e.g. in the mempool library header file:

extern int rte_mempool_logtype;
#define RTE_LOGTYPE_MEMPOOL     rte_mempool_logtype
+ #define MEMPOOL MEMPOOL
#define RTE_MEMPOOL_LOG(level, ...) \
        RTE_LOG_LINE(level, MEMPOOL, "" __VA_ARGS__)

-- 
You are receiving this mail because:
You are the assignee for the bug.