Add pack()/unpack() endianness modifiers for floating-point numbers

It passed with 11 votes in favor, none against and 5 abstaining, clearing the two-thirds majority it needed. Voting closed on March 13, 2026, and it targets PHP 8.6.

pack() turns values into raw bytes, and unpack() turns bytes back into values. Endianness is the order those bytes are written in: little-endian puts the least significant byte first, and big-endian puts the most significant byte first. This RFC from Alexandre Daubois lets you use the < and > modifiers to pick the byte order for floating-point formats.

Why it helps#

An earlier RFC already added < and > for integer formats in PHP 8.6, but floats still relied on their own letters. f and d use your machine's native order, g and G are floats in little or big order, and e and E are doubles in little or big order. That leaves you remembering which letter means what.

This RFC brings floats in line with integers. It also matches Perl, which already supports these modifiers on float codes.

How it looks#

// little endian
$data = pack('f<d<', 3.14159, 2.71828);

// big endian
$data = pack('f>d>', 3.14159, 2.71828);

// Unpacking
[$float, $double] = array_values(unpack('f<a/d<b', $data));

The new forms produce the same bytes as the existing letters:

pack('f<', 3.14) === pack('g', 3.14);
pack('f>', 3.14) === pack('G', 3.14);
pack('d<', 3.14) === pack('e', 3.14);
pack('d>', 3.14) === pack('E', 3.14);

The letters g, G, e and E already have a fixed byte order, so adding a modifier to them throws a ValueError:

pack('g<', 3.14); // ValueError

The RFC doesn't change how floats are encoded. It only adds a new way to write format codes that already exist.

What it means for existing code#

Nothing breaks. The new modifiers are opt-in, and your current format strings keep working. The RFC mentions that a later step could deprecate e, E, g and G, since Perl doesn't have them, but that isn't part of this proposal.