| Message ID | 20230210162626.3097660-1-ppluzhnikov@google.com |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] Use __builtin_FILE instead of __FILE__ in assert in C++. | expand |
On Feb 10 2023, Paul Pluzhnikov via Libc-alpha wrote:
> +# if !defined(__ASSERT_FILE)
Please remove the extra parens.
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,
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.*)?
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.
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) \
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(-)