Perl 5.40.1 repairs conversion at interpreter boundaries
Perl 5.40.1 restores strftime string conversion and repairs UTF-8 validation and regex compilation cleanup. The fixes explain how familiar Perl operations depend on interpreter ownership rules.
A formatting function can fail before it formats anything. In the regression fixed by Perl 5.40.1, POSIX::strftime could crash when its format argument was a number, an undefined value, or an object, including an object with overloaded string conversion. The function had stopped performing a conversion that callers could previously rely on. The release notes shipped with 5.40.1 identify the regression as beginning in the development series at 5.39.8.
The Perl history records date today's maintenance release to January 18. Its promise is limited and useful. The release declares no intentional incompatibilities with 5.40.0, while repairing failures in existing operations. There is no new application syntax to explain the upgrade. The relevant question is whether the implementation still honors the language behavior that existing programs expect.
Perl remains my choice for one-off text work after nearly thirty years. That preference makes these repairs interesting to me, because a short program still depends on substantial machinery for converting values and compiling patterns. The amount of code visible in a one-liner says little about the amount of interpreter code it exercises.
String conversion belongs to the interface
The strftime correction restores stringification of the first argument. The release notes distinguish actual strings from other values that need conversion, and explicitly include overloaded objects among the affected cases. That detail matters because an object can have a valid textual representation while requiring the interpreter to obtain it through the normal conversion mechanism.
An object with string overloading is therefore a stronger compatibility example than an accidentally supplied number. A caller can deliberately provide a value whose public behavior includes becoming a string. If the implementation assumes it already has ordinary string storage, it skips part of that behavior. Restoring conversion repairs the contract at the point where a Perl value enters the formatting implementation.
The reported symptoms also show why diagnosing this through application output alone can be misleading. The release notes mention an out-of-memory error as well as crashes. Neither symptom tells the caller that the format argument missed its expected conversion. A conversion failure can appear to be a resource problem much further inside the runtime.
This maintenance change does not require programs to start passing objects as formats. Plain format strings remain the most obvious expression of intent. Its significance is that existing legal conversions should not become interpreter failures merely because a runtime implementation changed. The 5.40.1 documentation describes the behavior as a restoration, which is the appropriate compatibility standard for this branch.
Invalid text has to remain invalid
Another repair concerns utf8n_to_uvchr(). The release notes say that some invalid UTF-8 sequences were not correctly recognized as invalid. Sequences beginning with continuation bytes or unassigned bytes could produce unexpected behavior or a panic. The correction restores detection and handling of these inputs, including related behavior in modules such as Encode.
This is a different boundary from stringification. Stringification asks a Perl value for its textual representation. UTF-8 validation asks whether a sequence of bytes is a valid representation in an encoding. A program can perform the first operation correctly and still receive malformed encoded data in the second. Combining the two under a vague description of Unicode support would hide the actual defects.
For text processing, rejection behavior is part of correctness. A parser that accepts a malformed sequence has changed the set of inputs that reach later operations. A parser that panics has prevented the caller from handling that input through the intended error behavior. The maintenance notes do not classify this correction as a new encoding policy. They describe an implementation failing to recognize inputs that were already invalid.
My preference for Perl's integrated text operations depends on those distinctions remaining understandable. There is value in concise matching and substitution, but concise syntax cannot compensate for an interpreter accepting a byte sequence under the wrong assumptions. Correct validation protects the meaning of every operation that follows it.
Failed compilation still owns resources
The regex fix addresses a double free or possible memory leak when certain patterns fail to compile. Successful matching is not required to reach the defect. Compilation itself allocates resources, and an unsuccessful compilation still has to release those resources according to their ownership.
The two reported outcomes describe different cleanup failures. Releasing the same allocation twice violates its lifetime. Failing to release an allocation leaves memory behind. The release notes identify both as possible consequences of the affected error handling. A malformed pattern therefore tests more than the quality of a diagnostic message. It also tests whether partial construction leaves the interpreter in a valid state.
This is particularly relevant to a language where regular expressions are ordinary expressions. Convenient syntax can make compilation seem incidental to matching. Perl must nevertheless handle patterns that cannot become executable matchers. The maintenance repair covers that unsuccessful path without asking application authors to rewrite their valid patterns.
Calling conventions can expose hidden assumptions
The release also repairs crashes or assertions when several builtin:: functions are invoked through a tail call with goto, or through call_sv() and related APIs. Affected functions include trim() and stringify(). The release notes identify a TARG handling bug, so the defect concerns interpreter result handling rather than the intended text operation itself.
An ordinary direct call and an alternate invocation path must still respect the callee's storage requirements. That is the useful connection between this fix and the conversion repairs. Values cross an implementation boundary under assumptions that are easy to miss when reading the application expression. Perl 5.40.1 repairs those assumptions within the existing stable interpreter, including cleanup when an operation fails before producing a result.