[Bug libc/18604] New: assert macro-expands its argument

["dak at gnu dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=18604

            Bug ID: 18604
           Summary: assert macro-expands its argument
           Product: glibc
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: dak at gnu dot org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 8394
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8394&action=edit
Sample program showing assert expanding its argument unnecessarily

The attached program produces the output
STRINGIFY(NULL): NULL
STRINGIFY2(NULL): ((void *)0)
a.out: test.c:11: main: Assertion `((void *)0)' failed.

It is a bad idea for assert to be expanding its argument since depending on the
condition it may lead to a completely unreadable mess: in my concrete case of a
failed assertion, I got some indecipherable 8-line output for a failed
assertion assert (SCM_MODULEP (module_));

The problem is that assert.h contains

# define assert(expr)                                                   \
  ((expr)                                                               \
   ? __ASSERT_VOID_CAST (0)                                             \
   : __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION))

Here __STRING(expr) needs to be replaced by #expr instead.  If the definition
of __STRING depends on available capabilities, then the check for the
capabilities has to be moved here, like

#if (HAVE_NORMAL_STRINGIFICATION)

# define assert(expr)                                                   \
  ((expr)                                                               \
   ? __ASSERT_VOID_CAST (0)                                             \
   : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION))

#else

# define assert(expr)                                                   \
  ((expr)                                                               \
   ? __ASSERT_VOID_CAST (0)                                             \
   : __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION))

#endif

An argument intended for stringification must not be passed to another macro
before being stringified or it will get prematurely expanded.  So the general
technique of __STRING is unfeasible when expansion is undesired, which it
clearly is in the case of assert.

Thank you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.