Hide function prototyes from unauthorized callers #23570
Conversation
regen/embed.pl
Outdated
| my $count = 0; | ||
| $count++ while $flags =~ /[ACX]/g; | ||
| die_at_end "$plain_func: A, C, and X flags are mutually exclusive" | ||
| if $count > 1; | ||
| $count = 0; | ||
| $count++ while $flags =~ /[ACE]/g; | ||
| die_at_end "$plain_func: A, C, and E flags are mutually exclusive" | ||
| if $count > 1; |
There was a problem hiding this comment.
These could be simplified:
die_at_end "..."
if $flags` =~ tr/ACX// > 1;
I thought the code was duplicated at first.
There was a problem hiding this comment.
There were several pre-existing places in the code where this could be used. I've added a commit to change those.
|
This warning from building pretty much every XS with and the cpphdrcheck hard failing for pretty much the same cause: |
|
TLDR: 60% chance this PR is a good idea with zero side effects and zero risk of current or future bug reports, and shaves a couple milliseconds off each CPAN .so/.dll build 40% chance bad idea, and there will be formal SEGV/fatal erroring bug tickets by 2030 linking to this commit's SHA1, or Perl ecosystem social media complaints and criticism published by October/November 2026 about this commit. Long story: If If its C lang Yeah, then seeing it at How else would the C compiler flood STDERR with warnings for undeclared functions? On ELF, I think b/c of its lazy load symbol resolution algorithm, end users won't know until they inject the My slight concern here is There are a dozen+ reasons for an entry to be marked with A bunch of other infrequent reasons its
if its really a convenience export for hacking or All of these kinds of Note, dropping the The 1 and only reference inside I also am starting to smell a tiny bit of smoke coming from unusual RISC CPUs/unusual commercial Unix OS/unusual and very rare non-Unix OSes. But this is all future-proof thinking, not middle of Aug 2025 thinking. Most likely real world failure mode for Perl dropping C Historical reasons would've been the "ordinal" (aka 0 based number) or More 2025-ish tech reason failure modes are "API versioning" or separating Swift vs Objective C vs C99 vs C++ vs JVM vs Go vs Fortran vs Rust symbols, all of which have the same source code ASCII identifier in their respective source code. Probably not a Perl problem because Perl VM uses But thinking in 2025-2030 era, what if a downstream consumer/sponsor of LLVM project, such as Apple or Google or Microsoft permanently removed the concept of Now theoretical concept of Swift vs Objective C vs C99 vs C++ vs JVM vs Go vs Fortran vs Rust symbols and C++-style ASCII string symbol name mangling isn't enough to stop a collision at process runtime, there would be 9 months-3 years of short-lived chaos for main stream private or FOSS C23/C++23 code bases if Clang/LLVM/iOS/Android/OSX dropped the concept of There is a real risk that by 2030, one of Perl's major OSes, WILL NOT support execution of homebrew ARM64 machine code. The insides of the executable ELF/Mach-o disk file called All ISO C lang code and all ISO C++ lang code and the Perl interp should never notice this 180 degree OS/CPU design change happened, but I can promise, there will be very visible Perl C level bugs, and Pure Perl level bugs when it happens. I want to say the last 3 paragraphs "This will never happen! Don't waste time planning for nonsense!" It already happened in 2024/2025 on a Production Grade Perl install on a real Production Grade OS with the highest Security, Uptime, and Performance in the world that money can buy. See this ticket: #23399 There have also have been 4 failed attempts in my life over the last 20 years to permanently kill off C/C++/Asssembly code once and forever, on the CPU silicon level. https://en.wikipedia.org/wiki/Jazelle WASM Perl + full C POSIX API access +full normal POSIX user perms, might be the only Perl build config for OSX by 2030. |
| @@ -2063,7 +2069,7 @@ Cp |const char *|moreswitches \ | |||
| Adp |void |mortal_destructor_sv \ | |||
| |NN SV *coderef \ | |||
| |NULLOK SV *args | |||
| CRTXip |char * |mortal_getenv |NN const char *str | |||
| CRTip |char * |mortal_getenv |NN const char *str | |||
There was a problem hiding this comment.
All of libperl's *getenv*() are messy, especially WinPerl's sandwich of functions and macros. 3 identical SV mortals/Newx blocks are made each time on WinPerl for no reason right now since Perl mid-5.30s.
I think but im not sure unless i do a deep dive study, that this function is one of the functions that will become semi-public CPAN API if WinPerl becomes MS UTF16-aware in the near future.
| |int flags | ||
| EXop |bool |try_amagic_un |int method \ | ||
| Xop |bool |try_amagic_un |int method \ |
There was a problem hiding this comment.
B::C and B::CC style modules may might want these symbols, but I have wanted to not-delete them and do major plastic surgery on their C prototypes/parameter order/parameter meanings for many months now.
The branch is 40% done and not syntax error-ing on 1 on these overload.pm getter callouts, I'm targeting -X file test operators first in my branch, because they have the worst abstraction split, between what the pp_*() func is responsible for and what the Public-to-CORE-only front-end C functions of overload.pm API are responsible for.
its mostly about this string/expression PL_op->op_type and is it caller function (the pp_*()s) or callee functions (overload.pm front ends) that derefs my_perl->Iop->op_type and do a tree of if/else branch logic on the U16 inside op_type
There was a problem hiding this comment.
B::CandB::CCstyle modules may might want these symbols, but I have wanted to not-delete them and do major plastic surgery on their C prototypes/parameter order/parameter meanings for many months now.
Would there is any interest from Unix only P5P ppl, to make the Win32/Win64 GH CI runners, dump the real symbol table of perl5xx.dll to STDERR/STDOUT inside a Win32/Win64 GH CI runner on each build?
Its 1279 lines (C symbols) long on perl543.dll right now.
Move these to a place common to both
I, and previous authors had forgotten that tr returns a count of matching characters, so can tell you if more than one character in the input string matches; as well as if none do.
It makes no sense to specify more than one of A C X, nor more than one of A C E. This commit enforces that, showing one entry in embed.fnc that needed to be changed.
0351a62 extended hiding private functions from callers into the gcc world. Some functions are allowed only in extensions; so can not be marked as hidden; this commit discourages their use however, by hiding their prototypes to all but the core and extensions. It turns out that four functions were being used in modules we ship with that were marked as extensions-only; so they had to be made globally accessible.
khwilliamson
force-pushed
the
invlist_contains_cp_
branch
from
4ab418b to
56f8f18
Compare
0351a62 extended hiding private functions from callers into the gcc world.
Some functions are allowed only in extensions; so can not be marked as hidden; this commit discourages their use however, by hiding their prototypes to all but the core and extensions.
It turns out that three functions were being used in modules we ship with that were marked as extensions-only; so they had to be made globally accessible.