Skip to content

Convert all calls to __ASSERT_() to assert_() #23573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: blead
Choose a base branch
from

Conversation

khwilliamson
Copy link
Contributor

The former symbol is undefined behavior in C and C++.

  • This set of changes does not require a perldelta entry.

The former symbol is undefined behavior in C and C++.
@bulk88
Copy link
Contributor

bulk88 commented Aug 15, 2025

https://github.com/search?q=%22define+__assert_%28%22&type=code 133 hits with current/old macro

https://github.com/search?q=%22define+assert_%28%22&type=code 696 hits with future proposed macro

the new preferred macro has much higher chance of a collision with 3rd party C headers

update:

Although a C compiler vendor should be calling the actual proc termination func

extern void _assert(const char * msg);

I have a suspicion this is a popular, not that brilliant choice, either in the past, or current, for C compiler authors, or random C library code bases.

extern void assert_(const char * msg);

@bulk88
Copy link
Contributor

bulk88 commented Aug 18, 2025

@mauke so as a professional developer, did you analyze which spelling of the token has the least likely hood of conflicts with 3rd party headers or not?

@tonycoz
Copy link
Contributor

tonycoz commented Aug 18, 2025

the new preferred macro has much higher chance of a collision with 3rd party C headers

The __ASSERT_() name is reserved to the implementation, which is probably why few others use it.

Although a C compiler vendor should be calling the actual proc termination func

extern void _assert(const char * msg);

_assert() is windows specific and irrelevant.

@mauke
Copy link
Contributor

mauke commented Aug 18, 2025

@mauke so as a professional developer, did you analyze which spelling of the token has the least likely hood of conflicts with 3rd party headers or not?

Yes, it's q_ac6f10cd_382f_4077_88e9_8e3e2c291ff3.

@khwilliamson
Copy link
Contributor Author

As a factoid, assert_() was added in 5.18. If its expansion conflicts with another definition, there would be a compiler warning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants