[committed][PATCH] Use __builtin_FILE instead of __FILE__ in assert in C++.

[committed][PATCH] Use __builtin_FILE instead of __FILE__ in assert in C++.

[Paul Pluzhnikov]

Likewise use __builtin_LINE instead of __LINE__.

When building C++, inline functions are required to have the exact same
sequence of tokens in every translation unit. But __FILE__ token, when
used in a header file, does not necessarily expand to the exact same
string literal, and that may cause compilation failure when C++ modules
are being used. (It would also cause unpredictable output on assertion
failure at runtime, but this rarely matters in practice.)

For example, given the following sources:

  // a.h
  #include <assert.h>
  inline void fn () { assert (0); }

  // a.cc
  #include "a.h"

  // b.cc
  #include "foo/../a.h"

preprocessing a.cc will yield a call to __assert_fail("0", "a.h", ...)
but b.cc will yield __assert_fail("0", "foo/../a.h", ...)
---
 assert/assert.h | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/assert/assert.h b/assert/assert.h
index 72209bc5e7..63197b819c 100644
--- a/assert/assert.h
+++ b/assert/assert.h
@@ -86,10 +86,21 @@ __END_DECLS
    parentheses around EXPR.  Otherwise, those added parentheses would
    suppress warnings we'd expect to be detected by gcc's -Wparentheses.  */
 # if defined __cplusplus
+#  if defined __has_builtin
+#   if __has_builtin (__builtin_FILE)
+#    define __ASSERT_FILE __builtin_FILE ()
+#    define __ASSERT_LINE __builtin_LINE ()
+#   endif
+#  endif
+#  if !defined(__ASSERT_FILE)
+#   define __ASSERT_FILE __FILE__
+#   define __ASSERT_LINE __LINE__
+#  endif
 #  define assert(expr)							\
      (static_cast <bool> (expr)						\
       ? void (0)							\
-      : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION))
+      : __assert_fail (#expr, __ASSERT_FILE, __ASSERT_LINE,             \
+                       __ASSERT_FUNCTION))
 # elif !defined __GNUC__ || defined __STRICT_ANSI__
 #  define assert(expr)							\
     ((expr)								\
-- 
2.39.1.581.gbfd45094c4-goog

Re: [committed][PATCH] Use __builtin_FILE instead of __FILE__ in assert in C++.

[Andreas Schwab]

On Feb 10 2023, Paul Pluzhnikov via Libc-alpha wrote:

> +#  if !defined(__ASSERT_FILE)

Please remove the extra parens.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [committed][PATCH] Use __builtin_FILE instead of __FILE__ in assert in C++.

[Paul Pluzhnikov]

On Fri, Feb 10, 2023 at 9:01 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Feb 10 2023, Paul Pluzhnikov via Libc-alpha wrote:
>
> > +#  if !defined(__ASSERT_FILE)
>
> Please remove the extra parens.

Done.

I was able to push amended patch (since there were no newer commits).
Is that what I should have done?

Thanks,
-- 
Paul Pluzhnikov

Re: [committed][PATCH] Use __builtin_FILE instead of __FILE__ in assert in C++.

[Joseph Myers]

On Fri, 10 Feb 2023, Paul Pluzhnikov via Libc-alpha wrote:

> I was able to push amended patch (since there were no newer commits).
> Is that what I should have done?

No, you should never do non-fast-forward pushes to master or other shared 
branches.  Carlos, could you investigate why the allow-non-fast-forward = 
(?!master|release.*) setting wasn't working to prevent such a push?  Is 
the setting being matched against full ref names and so considering 
refs/heads/master to match (?!master|release.*)?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [committed][PATCH] Use __builtin_FILE instead of __FILE__ in assert in C++.

[Carlos O'Donell]

On 2/10/23 16:56, Joseph Myers wrote:
> On Fri, 10 Feb 2023, Paul Pluzhnikov via Libc-alpha wrote:
> 
>> I was able to push amended patch (since there were no newer commits).
>> Is that what I should have done?
> 
> No, you should never do non-fast-forward pushes to master or other shared 
> branches.  Carlos, could you investigate why the allow-non-fast-forward = 
> (?!master|release.*) setting wasn't working to prevent such a push?  Is 
> the setting being matched against full ref names and so considering 
> refs/heads/master to match (?!master|release.*)?
> 

Yes, I'll look at this. This shouldn't be allowed.

-- 
Cheers,
Carlos.