glibc 2.38 makes binary input a standards-mode decision

Adding a number syntax to a runtime parser changes which input strings an existing program accepts. That creates a compatibility question even when the function's name and parameters stay the same. glibc 2.38 handles binary integer prefixes through a standards-mode distinction, with headers selecting the appropriate parsing interface.

The July 31 announcement says the integer conversion functions accept 0b and 0B prefixes when C2x features are enabled and the base argument is zero or two. This includes the familiar strtol family, their locale variants, and corresponding wide-character functions. The qualification about enabled features is part of the change.

C remains an important interface language for me, and this is the sort of detail that makes runtime compatibility interesting. A source-level call can keep its spelling while the accepted input grammar changes. The library needs to expose the new behavior without pretending that the old and new parsing contracts are identical.

The base argument is only part of the request

A conversion function receives a string and a base. In the new C2x behavior, a base of zero or two permits the binary prefix described in the announcement. That means the string's notation and the caller's selected base jointly determine what the parser recognizes.

A short example shows the intended input under the enabled C2x interfaces:

#include <stdlib.h>

int main(void)
{
    char *end;
    long value = strtol("0b101", &end, 0);
    return value == 5 && *end == '\0' ? 0 : 1;
}

The example checks both the value and whether the complete string was consumed. It is deliberately limited to a small representable value. It illustrates the new prefix rule without claiming to be a complete parser for arbitrary input or to handle every error case.

The language mode and runtime headers matter to that result. The announcement does not say that every existing strtol call in every build starts accepting the new prefix. It specifically places the behavior behind C2x feature selection. That lets the same library support callers with different expectations about accepted syntax.

This is relevant to file formats and command-line grammars. If a program delegates numeric interpretation to a runtime function, its effective input language depends partly on the selected library interface. Adopting a new standard mode can therefore have externally visible effects without any edit to the call itself.

The header records the compatibility choice

The glibc 2.38 stdlib header shows the implementation of the distinction. Under its C2x integer-conversion feature condition, it redirects strtol to __isoc23_strtol. Related functions redirect to corresponding C23 names.

The source also contains a fallback arrangement using macro mappings when the redirection facility is unavailable. In either case, the ordinary source spelling can select a different external interface. The internal condition and symbol names are implementation details, but they explain how the library can preserve distinct behaviors behind familiar source declarations.

This has a deployment implication. New headers and their selected symbols are part of what determines a program's runtime requirements. A successful compile does not establish that an older installed library supplies every symbol named by the linked output. The relevant question includes which interface the headers selected.

For me, this is a useful reminder that C interoperation includes more than matching argument types. The accepted grammar of a conversion and the symbol selected for it also form part of the contract. Keeping that distinction explicit is preferable to describing the release as a universal change to every old call.

Scanning has its own documented conditions

The announcement separately describes formatted input. With C2x features enabled, %i conversions accept binary integers carrying the prefix. The same family also gains %b for binary integers with or without the prefix, independently of standards mode.

Those are different entry conditions. A caller relying on automatic notation recognition through %i must account for the selected standards features. A caller explicitly choosing binary conversion through %b states its intent in the format string. The announcement includes narrow and wide formatted-input functions in this description.

glibc also adds the C2x PRIb*, PRIB*, and SCNb* macros to inttypes.h. These extend the named formatting and scanning support associated with integer types. Their addition belongs to the library component of standard support, separate from whether a compiler recognizes a binary literal in source code.

That distinction matters when evaluating a toolchain. A compiler can understand source syntax while the runtime lacks the corresponding conversion behavior. Conversely, library support for parsing a string does not establish support for every C2x language feature. A working configuration combines the compiler, headers, and runtime facilities actually used.

Fixed-width formatting gains another spelling

The release adds wN length modifiers for fixed-width and least-width integer types. Its examples include %w32d for decimal output and %w32x for hexadecimal output of the corresponding unsigned types. It also adds wfN modifiers for fast integer types.

These modifiers make a type-related choice visible in the format itself. They do not remove the obligation to pass an argument of the expected type. The format string remains a contract between the caller and a variadic function, and the new notation supplies additional ways to express that contract.

The same announcement includes a formatting security correction, CVE-2023-25139. It concerns grouping together with a minimum width and output larger than a caller might reasonably expect from a tight buffer bound. That correction is separate from binary parsing but reinforces how much behavior a short format string can request.

AArch64 vector math has an ABI qualification

glibc 2.38 also adds AArch64 libmvec support. The announcement requires GCC 10.1.0 or newer for that build and says the symbols follow the AArch64 vector ABI. At this stage the functions must be called manually.

Disabling this support has an ABI consequence. The announcement says --disable-mathvec can disable it, but explicitly calls that an unsupported configuration because it changes the ABI. Availability of a configure switch is therefore not the same as a supported runtime variant.

The release's parsing and vector-library changes both require attention to the selected interface. Binary conversion depends on the standards features exposed by the headers. AArch64 vector math adds symbols with a specified ABI and a documented build requirement. In both cases, the practical contract is more precise than the compiler or library version alone.