Perl 5.27.7 extends the j integer format modifier
The j size modifier no longer requires a C99 compiler to build Perl. Its width still depends on the platform, so the change expands availability without defining a fixed-width format.
Supporting a format modifier on more compilers does not make its numeric width identical across machines. Perl 5.27.7 extends the sprintf j size modifier to builds using pre-C99 compilers. The release notes immediately qualify the change by stating that its actual size remains platform-dependent. The release history records December 20, 2017. This is a portability improvement in availability, with an explicit limit on representation.
The distinction is easy to lose in a short release summary. A format can become accepted by a wider set of Perl builds while still interpreting integers according to those builds' native types. Code that requires a particular wire representation cannot infer its integer width merely from the presence of the letter j.
I value precise formatting in one-off text work because the resulting output is often the whole purpose of the program. A modifier that names a native integer type is useful when that is the intended interpretation. It needs a different explanation from a promise that an output field has the same range on every platform.
A size modifier qualifies a conversion
The function documentation shipped with this version describes integer size modifiers in terms of C types supported by the compiler used to build Perl. The j modifier requests interpretation as intmax_t. Other modifiers refer to types such as short, long, ptrdiff_t and size_t.
The modifier accompanies a conversion character. For a signed decimal conversion, a small example is:
my $text = sprintf "%jd", 42;
Here d selects the integer conversion and j supplies its size interpretation. The example deliberately uses a small value. It demonstrates the format without implying a platform-independent maximum that the release does not establish.
The documentation also explains that ordinary integer conversions otherwise assume the default integer size on the platform. Choosing a modifier can change that interpretation to a named C type. It does not remove the relationship between formatting and the interpreter's build configuration.
Availability and failure policy are separate
The release's addition concerns compiler support. A program that needs to run across different installed Perl versions still has to distinguish the new snapshot from older builds. The existence of a source-level format string does not establish what every interpreter on a machine accepts.
The function documentation says unsupported size flags do not raise an exception by default. With warnings enabled, they generate a warning in the printf warning class. A caller that wants an exception can promote that class to fatal warnings:
use warnings FATAL => 'printf';
This controls how an unsupported formatting request is reported. It does not change the type's width or add compiler support to an old interpreter. The distinction lets a script choose a stricter failure policy without pretending that warning configuration changes the underlying numeric representation.
For my purposes, that explicit failure policy is preferable when a formatting assumption is essential to the output. A report that silently falls back after an unsupported flag can be harder to interpret than a program that stops at the incorrect assumption. The documented warning category provides a direct way to express that requirement.
Larger unpack results require a larger count type
Another change in this snapshot updates the C API return types of unpackstring() and unpack_str() from I32 to SSize_t. The notes connect the change to datasets containing more than two billion items. pack and unpack also gain support for repeat counts and lengths beyond that size.
These changes address a different boundary from integer output formatting. The C API must be able to report how many items the operation produced. A wider supported input or result is not useful if an intermediate count type cannot represent it. Extension code using the API needs to account for its revised return type.
The notes do not claim that such operations now need little memory. Supporting the count removes one representational limit, while actual allocation remains a separate concern. The same release repairs Perl's own allocator when asked for more than a gigabyte on a 64-bit platform, which illustrates another implementation boundary involved in large requests.
String conversion happens before process execution
The snapshot also changes system to stringify its arguments in the parent process. Overload methods and warnings triggered by stringification therefore have effects visible where the program expects them. This is a useful correction for values whose conversion performs work beyond returning an already available plain string.
Related fixes protect argument lists for exec, system and similar operations against reentrant calls and magic such as tied scalars. These changes concern when Perl prepares values and how it preserves them during preparation. They give the December release a broader theme of keeping conversions and their internal representation accurate, including the platform-specific size contract of the new j support.