Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: bbc7f9cd1ee7996078b5ca6c40db3657788317a9
https://github.com/Perl/perl5/commit/bbc7f9cd1ee7996078b5ca6c40db3657788317a9
Author: Karl Williamson <[email protected]>
Date: 2026-01-22 (Thu, 22 Jan 2026)
Changed paths:
M hv_func.h
M hv_macro.h
M perl_inc_macro.h
M regcomp_internal.h
M sbox32_hash.h
M zaphod32_hash.h
Log Message:
-----------
Standardize .h recursive #include guard names
Some header files in the Perl core have guards to keep a
recursive #include from compiling them again. This is standard practice
in C coding, and I was surprised at how many headers don't have
it. These seem to rely on only being included from perl.h, which does
have its own guard.
Most of the guards use a common naming convention. If the file is named
foo.h, the guard is named 'PERL_FOO_H'. Often, though, a trailing
underscore is added, 'PERL_FOO_H_', making the convention slightly
fuzzy. The 'PERL_' is not added if the file 'foo' already includes
'perl' in its name,
Those rules are enough to describe all the guards in the core, except
for the outliers in this commit, plus perl.h.
There are occasions in various Perl scripts that examine our source that
we want to create a pattern that matches the header guard name for a
particular file. In spite of the slight fuzziness, that's easy using
the above rules, except for the ones in this commit, and perl.h.
It would be better for that code to not have to worry about the
outliers, and since these are arbitrary names, we can just change them
to follow the rules that already apply to most.
This commit changes the names of the outliers so that the only file the
rules don't apply to is perl.h. Its guard is named H_PERL. That
spelling is used in Encode, so it's not so easy to change it seamlessly.
I'm willing to live with it continuing to be an outlier for the code I
write.
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
