-
Notifications
You must be signed in to change notification settings - Fork 586
don't call vivifier macros Perl_error_log/Perl_debug_log in a loop #23356
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
base: blead
Are you sure you want to change the base?
don't call vivifier macros Perl_error_log/Perl_debug_log in a loop #23356
Conversation
bulk88
commented
Jun 5, 2025
- macros Perl_error_log/Perl_debug_log internally call exported function PerlIO_stderr(my_perl) which may or may not call Newxz() or calloc(). A naive person would think these macros are PL_something my_perl->Isomething vars or they are C image globals vars. These 2 macros are not simple data var derefs, but are in fact vivifing function calls. Probably 20-30 years, before PerlIO was invented, I will guess Perl_error_log/Perl_debug_log where just "#define Perl_error_log 2".
- Fix this by caching the PerlIO * ptrs to C autos.
- Why the PerlIO API is NULL ptr, and why these vivifier function calls need to be called everywhere in all of core, at all PL_phases of execution, is beyond the scope of this commit.
- This set of changes does not require a perldelta entry.
- macros Perl_error_log/Perl_debug_log internally call exported function PerlIO_stderr(my_perl) which may or may not call Newxz() or calloc(). A naive person would think these macros are PL_something my_perl->Isomething vars or they are C image globals vars. These 2 macros are not simple data var derefs, but are in fact vivifing function calls. Probably 20-30 years, before PerlIO was invented, I will guess Perl_error_log/Perl_debug_log where just "#define Perl_error_log 2". - Fix this by caching the PerlIO * ptrs to C autos. - Why the PerlIO API is NULL ptr, and why these vivifier function calls need to be called everywhere in all of core, at all PL_phases of execution, is beyond the scope of this commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that a more general solution would be better. Would making these inline functions be sufficient?
Also, I will forcefully object to committing anything that doesn't have a readable commit message, as this one isn't. There need to be paragraphs, and not run-on sentences, and proper English grammar.
This sounds like stream-of-contagiousness writing. It is unfair to code reviewers and people reading the commit in the future to not communicate in clear prose.
Then go read the code then without looking at the commit message. If someone don't understand the C lang, or intentionally doesn't want to learn about how a certain XS/C Perl API actually works, because its TMI for them and a waste of productivity, I can't help them. |
|
||
PERL_ARGS_ASSERT_DUMP_SUB_PERL; | ||
|
||
cv = isGV_with_GP(gv) ? GvCV(gv) : CV_FROM_REF((SV*)gv); | ||
cv = (is_gv = cBOOL(isGV_with_GP(gv))) ? GvCV(gv) : CV_FROM_REF((SV*)gv); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not fond of this sort of assignment inside assignment, why not split it up in two statements to make things easier to read?
I can't help wondering if that wouldn't be the better fix than this, but I also don't know why these are lazily vivified. |
How did you conclude this? |
On Fri, Jul 11, 2025 at 12:49:56PM -0700, bulk88 wrote:
Then go read the code then without looking at the commit message. If
someone don't understand the C lang, or intentionally doesn't want to
learn about how a certain XS/C Perl API actually works, because its TMI
for them and a waste of productivity, I can't help them.
I for one will firmly object to any of your PRs getting accepted unless
they have a comprehensible commit message. You are of course free for now
to continue submitting PRs with rubbish commit messages, but the people
with commit bits are free to refuse to commit them.
…--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"
|
Line 5273 in 9ef5300
What is there to inline here? How would changing this func from exported func to How is a C compiler supposed to prove that Since
how is the |
I wish that too. But I've stared at Here is the ctor after I set a BP.
Line 4688 in 9ef5300
But IDK, to positively say in the future, "the code is wrong and not following Perl 5's C API, there is no bug inside the Interp, the Reporter's code defective and buggy, ticket rejected". if one day, some small piece of code, regardless of its author or origins or maintainer, replaces Or uses So IDK enough about PerlIO's design requirements, to just delete that NULL check and the fast path/slow path branches that happen inside Caching the pointer in caller frames, where manual screening shows the callers aren't doing risk/dangerous things like |
As a contributor to the Perl5 project, I believe I have the responsibility to not deliberately change anything that isn't beneficial to the project As a person who has commit rights, I am confident that I have the responsibility to not commit something that I believe isn't beneficial, and I have the responsibility to object to another committer adding something non-beneficial. Commit messages are important. @bulk88 may not think so. But I do, and so do many more people. It is part of my responsibility to try to allow only good commit messages into blead. A commit message that wastes people's time should not be allowed in. |