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

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

[dak at gnu dot 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.

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

[dak at gnu dot org]

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

--- Comment #1 from David Kastrup <dak at gnu dot org> ---
This has been the case at least for 20 years:

https://sourceware.org/git/?p=glibc.git;a=blob;f=assert/assert.h;hb=28f540f45bbacd939bfd07f213bcad2bf730b1bf

which is the "initial import" in the Git repository (at a time when Git did not
even exist).

I'm surprised there has not been more of a pushback against it.  At any rate,
__STRING is either <em>intended</em> to macro-expand its argument (and there
are use cases for that, like when putting version numbers possibly assembled by
macros into diagnostics) and then its use in "assert" has always been an error,
or it is supposed to cater for non-ANSI preprocessors.

I think we can safely assume that those are gone, even if in 1995 some might
have been around still.

So instead of __STRING(expr) this should really be #expr here.

Thanks.

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

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

[schwab@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
glibc doesn't support pre-standard preprocessors since 15 years.

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

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

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
For early history try git://repo.or.cz/glibc/history (a conversion without 
the heuristics to combine commits to different files from the same 
changeset that were committed with per-file log messages that caused 
problems for some of the earlier history).  The initial version of 
assert.h there from 1991 has (commit 
c2547ce6a46f905a7f876f3e2c35e6e9e9b36527):

+/* IGNORE($    */
+#ifdef __STDC__
+/* $) IFANSI($ */
+#define        __assert_quotearg(s)    #s
+/* $) IGNORE($ */
+#else  /* Not ANSI C.  */
+/* $) IFTRAD($ */
+#define        __assert_quotearg(s)    "s"
+/* $) IGNORE($ */
+#endif /* ANSI C.  */
+/* $)  */

which suggests that pre-ISO C may have been a reason for how this was done 
(although pre-ISO C is no longer a concern now and I agree it would make 
sense to stop macro-expanding here).

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

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

[dak at gnu dot org]

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

--- Comment #4 from David Kastrup <dak at gnu dot org> ---
So it would seem that replacing __STRING(expr) with #expr in assert.h would be
the right thing to do.

What do I have to do in order to get any progress on this?  Request commit
access on Savannah and then push an appropriate change?

Or is there any less hands-on approach to get a fix in?

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

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

[dak at gnu dot org]

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

--- Comment #5 from David Kastrup <dak at gnu dot org> ---
(In reply to David Kastrup from comment #4)
> So it would seem that replacing __STRING(expr) with #expr in assert.h would
> be the right thing to do.
> 
> What do I have to do in order to get any progress on this?  Request commit
> access on Savannah and then push an appropriate change?
> 
> Or is there any less hands-on approach to get a fix in?

Is everybody dead?  Come on, answering this is not going to take more than one
minute of your time.  Unless there is no answer, and that would mean that the
project setup is fundamentally broken.

What do I have to do in order to get any progress on this issue?

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

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

[msebor at redhat dot com]

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

Martin Sebor <msebor at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at redhat dot com

--- Comment #6 from Martin Sebor <msebor at redhat dot com> ---
You can find some background in section 5.1. Contributing on the GLIBC Wiki:

https://sourceware.org/glibc/wiki/HomePage

Alternatively, you can wait until someone else picks up this bug and sends in a
patch of their own.

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

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

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
https://sourceware.org/glibc/wiki/Contribution%20checklist

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