Skip to content

scope_types.h dont include a const static char arr [59]; in every TU #23372

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

bulk88
Copy link
Contributor

@bulk88 bulk88 commented Jun 15, 2025

This array is 59 bytes long, and is rounded to 64 bytes of .rdata storage. While all commercial/big FOSS CCs will correctly discard this unreferenced array during link phase (.o/.obj -> .exe/.dll). There is no reason for every TU/.o file to have this 64 byte array sitting in it. This was caused by a mistake in the initial commit of scope_types.h, when this array was moved out of scope.c to a .h.

commit 721bab5 - Yves Orton - 10/31/2022 6:37:27 AM scope_types.h - new header file for scope type data Next patch this data will be autogenerated.

To fix this, I choose instead of feature switching it behind a very narrow and "not for CPAN"

#ifdef PERL_IN_SCOPE_C

I decided for flexibility if B::Foo or Devel::Foo on CPAN in the future wants this array they can ask for it with

#define WANT_LEAVE_SCOPE_ARG_COUNTS

also reduce white space for a tiny bit faster compile times (theoretical).


  • This set of changes does not require a perldelta entry.
This array is 59 bytes long, and is rounded to 64 bytes of .rdata storage.
While all commercial/big FOSS CCs will correctly discard this unreferenced
array during link phase (.o/.obj -> .exe/.dll). There is no reason for
every TU/.o file to have this 64 byte array sitting in it. This was caused
by a mistake in the initial commit of scope_types.h, when this array
was moved out of scope.c to a .h.

commit 721bab5 - Yves Orton - 10/31/2022 6:37:27 AM
scope_types.h - new header file for scope type data
Next patch this data will be autogenerated.

To fix this, I choose instead of feature switching it behind a very
narrow and "not for CPAN"

#ifdef PERL_IN_SCOPE_C

I decided for flexibility if B::Foo or Devel::Foo on CPAN in the future
wants this array they can ask for it with

#define WANT_LEAVE_SCOPE_ARG_COUNTS

also reduce white space for a tiny bit faster compile times (theoretical).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant