Skip to content

XSUB.h: fix C23 incompatibility in XSINTERFACE_* macros #23194

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

Closed
wants to merge 1 commit into from

Conversation

xenu
Copy link
Member

@xenu xenu commented Apr 13, 2025

In C23, the meaning of an empty function prototype has changed. It used to mean "unspecified number of arguments", but it has now changed to "no arguments".

Fixes #23192

In C23, the meaning of an empty function prototype has changed. It used
to mean "unspecified number of arguments", but it has now changed to "no
arguments".

Fixes Perl#23192
@jkeenan
Copy link
Contributor

jkeenan commented Apr 13, 2025

In C23, the meaning of an empty function prototype has changed. It used to mean "unspecified number of arguments", but it has now changed to "no arguments".

Do you anticipate a similar change in clang?

@xenu
Copy link
Member Author

xenu commented Apr 13, 2025

So far, clang hasn't bumped the standard C version (they're still at C17), but it's likely they will at some point in the future.

If you use clang >=18, you can force it by configuring Perl with -Accflags=-std=gnu23. Building CommonMark should fail in the same way as in the bug report, and my PR should fix it.

GCC 14 would also fail with this flag, but unfortunately my fix doesn't work for this particular version, because GCC 14 does not set __STDC_VERSION__ properly. As this is a rather unusual configuration, I don't think working around it would be worth it.

@Leont
Copy link
Contributor

Leont commented Apr 13, 2025

I'm not sure this fix is right (I have to dig deeper for that), but I am very sure that the implementation of the INTERFACE feature is rather broken and should probably be fixed.

xsubpp knows the types of the arguments of the function, it should be able to cast to the right type without needing this silly macro.

@xenu
Copy link
Member Author

xenu commented Apr 13, 2025

While it being UB isn't very surprising, I thought it's at least one of those things that work in practice. And it is on most platforms, but apparently not on macOS on Apple Silicon, which uses a special ABI for vararg functions.

Oh well, I guess we will have to fix it the hard way.

@xenu xenu closed this Apr 13, 2025
@thesamesam
Copy link

thesamesam commented Apr 13, 2025

Right, calling it via ... isn't OK unless the real function genuinely is variadic. Definitely was broken for C++ before.

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.

The CommonMark module cannot be built using gcc 15 and perl 5.40.1
4 participants