Skip to content
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

S_new_SV: mark args unused, make inline, correct typo #22208

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

Conversation

richardleach
Copy link
Contributor

When sv_inline.h was created in
75acd14
and a number of things moved into it, the S_new_SV debugging function should
have been made PERL_STATIC_INLINE. This commit now does that.It also marks
the arguments to S_new_SV as PERL_UNUSED_ARG, reducing warnings on some
builds, and corrects a transcription error in the FUNCTION argument.

The first two changes were suggested in #22125 and the third noticed during
preparation of this PR.

sv_inline.h Outdated Show resolved Hide resolved
@richardleach richardleach force-pushed the hydahy/22125_leaking_scalars_inline branch from b3717a0 to 250be70 Compare May 11, 2024 17:19
@tonycoz
Copy link
Contributor

tonycoz commented May 13, 2024

Something that I should have picked up from the original commit: S_new_SV() is visible outside of perl itself, and like the other visible inline functions it should use a Perl_ prefix.

Looks fine otherwise.

@richardleach richardleach force-pushed the hydahy/22125_leaking_scalars_inline branch from 250be70 to 1c16f24 Compare May 13, 2024 20:37
@iabyn
Copy link
Contributor

iabyn commented May 20, 2024

I think S_new_SV() should be made always defined, not just existing on DEBUG_LEAKING_SCALARS builds; but with the extra sv->sv_debug* and logging lines wrapped in ifdef DEBUG_LEAKING_SCALARS. Then the macro new_SV() should stop being a multi-line macro and just become a call to the inline function S_new_SV(). Then the code comment "provide a real function for a debugger to play with" becomes redundant.

The weird "sometimes a macro, sometimes a function" arrangement was put in place by me back before we could use inline functions.

It should probably also have an entry in embed.fnc?

@khwilliamson
Copy link
Contributor

Yes it should have an embed.fnc entry

@richardleach
Copy link
Contributor Author

Ok, will work on that.

@richardleach richardleach force-pushed the hydahy/22125_leaking_scalars_inline branch from 1c16f24 to fdbd16f Compare May 22, 2024 23:05
{
SV* sv;
PERL_UNUSED_ARG(file);
PERL_UNUSED_ARG(line);
PERL_UNUSED_ARG(func);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three variables are used when DEBUG_LEAKING_SCALARS is defined. Maybe these should be wrapped with a #ifndef DEBUG_LEAKING_SCALARS ... #endif.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can do that.

@richardleach richardleach force-pushed the hydahy/22125_leaking_scalars_inline branch from fdbd16f to ddecdf3 Compare May 23, 2024 19:10
When sv_inline.h was created in
Perl@75acd14
and a number of things moved into it, the S_new_SV debugging function should
have been made PERL_STATIC_INLINE and given the Perl_ prefix. This commit
now does those things. It also marks the arguments to Perl_new_SV as
PERL_UNUSED_ARG, reducing warnings on some builds.

Additionally, now that we can use inline functions, the new_SV() macro is
now just a call to this inline function, rather than being that only on
DEBUG_LEAKING_SCALARS builds and a multi-line macro the rest of the time.
@richardleach richardleach force-pushed the hydahy/22125_leaking_scalars_inline branch from ddecdf3 to ececbcf Compare May 23, 2024 21:49
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.

None yet

6 participants