Fix GH-17068: Add pack()/unpack() format for signed integer endianness

[alexandre-daubois]

Fix #17068

Adds signed integer endianness support to pack()/unpack() functions. There are 2 new format codes (from the original issue): m/y for signed 2-byte (little/big endian), M/Y for signed 4-byte (little/big endian), and p/j for signed 8-byte (little/big endian). It follows the existing pattern where lowercase matches uppercase endianness.

I also moved pack tests in a dedicated folder.

[NattyNarwhal]

Passes on a big endian system

[alexandre-daubois]

Friendly ping @php/release-managers, would you prefer to wait or are you comfortable with this change?

[DanielEScherzer]

RM approval, technical review not performed

[nielsdos]

Technically this looks okay.
I didn't understand the reasoning behind picking the letters for the format, and the original issue description didn't help me understand it either. The original issue comment talks about "to match the other formats" but I didn't understand this. Can you please explain?

[alexandre-daubois]

I followed the current convention where lowercase is little endian, and uppercase is big endian.

About the letters themselves, I'm not sure there's a technical justification other than "these letters are not already used in pack/unpack". Maybe I miss something and the letters may actually have a deeper meaning?

[nielsdos]

I followed the current convention where lowercase is little endian, and uppercase is big endian.

You didn't follow this.
Also this doesn't seem to be the convention. It seems mostly true though.
Thing is I want to be sure about the choice as we'd be stuck with this forever.

[alexandre-daubois]

Indeed, I've got it all mixed up. It's no good as it is.
Would this logic work? If so, I'll update the PR accordingly.

[nielsdos]

Indeed, I've got it all mixed up. It's no good as it is. Would this logic work? If so, I'll update the PR accordingly.

Possibly, but honestly the more I look at the table the less the naming scheme makes sense, I just don't get it. Someone else will have to judge what the right letters are...

[TimWolla]

This should match Perl: https://perldoc.perl.org/functions/pack

>   sSiIlLqQ   Force big-endian byte-order on the type.
    jJfFdDpP   (The "big end" touches the construct.)

<   sSiIlLqQ   Force little-endian byte-order on the type.
    jJfFdDpP   (The "little end" touches the construct.)

[alexandre-daubois]

Hmmm... PERL uses < and > modifiers for endianness, which isn't compatible with the current implementation of pack/unpack that only accept one char. Thus we cannot match PERL's pack exactly. I'm not sure how we should proceed here apart from taking arbitrary letters?

[cmb69]

In my opinion, it's better to pursue the RFC process here, instead of adding some arbitrary characters which might later interfere with further additions.

[alexandre-daubois]

Looks like the best thing to do here. Let's pause this PR for now