This is a final summary of the state of the new ref-counted stack
facility at the 5.40.0 release: and is intended to be added to the
5.40.0 perldelta, to replace (rather than than be in addition to) any
earlier mentions of PERL_RC_STACK in the 5.39.2 and .6 perldeltas.
S_ENFMT properly belongs to the group of permission bits (like
setuid/setgid), not file types. On systems that have it (like AIX), it
can be set/cleared with chmod(). (In fact, it usually shares its value
with S_ISGID because enforced locking is signaled by the combination of
a non-executable file with the setgid bit set.)
S_IFMT($mode) directly gives you one of the file types (S_IFREG,
S_IFDIR, etc). You don't need to bit-and it further (especially not with
the S_IS* functions), contrary to what the comment claims. (The
confusion likely stems from the C side of things, where you'd do `mode &
S_IFMT` to extract the file type from the mode bits, leading to code
like `(mode & S_IFMT) == S_IFDIR`. But even then you could write
`S_ISDIR(mode)` without any bit mask trickery.)
Most of the symbols in the "S_IF* constants" section don't start with
"S_IF", so change to "S_I* constants" everywhere.
Most of the symbols in the "S_IF* functions" section don't start with
"S_IF" (with the sole exception of S_IFMT, which is only a function in
Perl; the C macro is a constant).
(Historical note: This section label used to make more sense because it
documented S_IFMODE and S_IFMT functions, but the former was just a typo
for S_IMODE.)
The docs for lexical variable declarations referenced 'local' as a mechanism to declare global variables in a couple instances, which is incorrect. 'local' only localizes global variables, it doesn't create or declare them in the common case where strict 'vars' is in effect.
Update some obsolete Perl book URLs. Convert some HTTP links to HTTPS.
Wrap links in `L<>`.
Committer: Resolve merge conflicts in pod/perllocale.pod.
For: https://github.com/Perl/perl5/pull/22186
When using versions with underscores, best practice is to remove the
underscore on a later line, to allow using the version as a number when
accessing the variable directly.
The reeproducer resulted in the "block" OP being both on the parser
stack and attacked to the CV. If an error occurred while parsing the
rest of the list operator clean up would release the OP as attached
to the CV, and the same OP on the parse stack, resulting in a double
free.
It's unclear to me whether bison is intended to support modifying
the parse stack entry like this, but it appears to work here.
Fixes#21724
- Remove duplicate sections: File::Glob::glob, bare { in regexes, code
points above 0xFF in string bitwise ops
These were repeated for different perl versions, but none of the other
sections list deprecations and removal separately (e.g. "Passing
malformed strings was deprecated in Perl 5.18, and became fatal in
Perl 5.26" only appears under Perl 5.26; the deprecation is not listed
separately under Perl 5.18).
- Fix some typos (e.g. "ballanced")
- Fix (?) some grammar/punctuation
Also use past tense to describe removed functions.
- Fix some POD markup (C< > around variables, L< > for modules)
ae3e9dd0b was intended to disable this API, due to a leak in the
DragonflyBSD implementation, but the wrong macro was used, which
I missed in review.
Use the right macro.
We need to save the value of PL_prevailing_version at the time the eval
op was compiled, so it can be put in place during the running code.
Ideally we'd do something more robust, like change the OP_ENTERVAL op
class into UNOP_AUX, so that the aux vector can store additional
information like the version number and perhaps the frozen hints hash.
In practice it is far too close to the 5.40 release to contemplate such
a change now, so this is a less intrusive but hackier change to achieve
the same aim.
See also
https://github.com/Perl/perl5/issues/22121
2.038 2024-04-15
[CHANGES]
* Add extra TCP_ and IPV6_ constants for Linux (RT143712)
[BUGFIXES]
* Account for newer Solaris behaviour on AF_UNIX address length
(RT152866)
This fixes GH #21562
Perl doesn't support all possible locales. Locales that remap elements
of the ASCII character set or change their case pairs won't work fully,
for example. Hence, some Turkish locales arent supported because
Turkish has different behavior in regard to 'I' and 'i' than other
locales that use the Latin alphabet.
The only multi-byte locales that perl supports are UTF-8 ones (and there
actually is special handling here to support Turkish). Other multi-byte
locales can be dangerous to use, possibly crashing or hanging the Perl
interpreter. Locales with shift states are particularly prone to this.
Since perl is written in C, there is always an underlying locale. But
most C functions don't look at locales at all, and the Perl interpreter
takes care to call the ones that do only within the scope of 'use
locale' or for certain function calls in the POSIX:: module that always
use the program's current underlying locale.
Prior to this commit, if a dangerous locale underlied the program at
startup, a warning to that effect was emitted, even if that locale never
gets accessed.
This commit changes things so that no warning is output until and if the
dangerous underlying locale is actually attempted to be used.
Pre-existing code also deferred warnings about locales (like the Turkish
ones mentioned above) that aren't fully compatible with perl. So it was
a simple matter to just modify this code a bit, and add some extra
checks for sane locales being in effect
This occurs with clang-17, and possibly other versions:
regcomp_trie.c:667:13: warning: variable 'wordlen' set but not used [-Wunused-but-set-variable]
667 | U32 wordlen = 0; /* required init */
| ^
This happens because while the first loop in Perl_make_trie calculates
wordlen, mostly via the TRIE_READ_CHAR macro, that calculated value
isn't used.
The later loops do use the value of wordlen via the TRIE_HANDLE_WORD()
macro.
Unfortunately the use in TRIE_READ_CHAR() means we can't remove
this first definition, so suppress the warning.
For a non-debugging build this would warn with clang 17:
regcomp_study.c:1067:9: warning: variable 'merged' set but not used [-Wunused-but-set-variable]
1067 | U32 merged = 0;
| ^
and briefly document the undocumented messages it found.
Note that the "Odd number of arguments" message isn't suppressible,
I do not know if that is by design:
$ ./perl -Ilib -Mfeature=class -e 'no warnings; class C { field $x:param; } C->new("x")'
Odd number of arguments passed to "C" constructor at -e line 1.
Discovered when porting/diag.t didn't warn about my new message
in the fix for #22159
