Reversed packed strings

[Y-Less]

Is this a BUG REPORT, FEATURE REQUEST or QUESTION?:

• [ ] Bug Report
• [x] Feature Request
• [ ] Question

What happened:

This code:

new x = !"hello there";

Will compile as a packed string. The in-memory representation of this, in byte order, is:

llehht o\0ere

Every 4 bytes are reversed, as the whole thing is stored big-endian in cells.

What you expected to happen:

Packed strings should be stored as C strings, in memory order on little-endian machines:

hello there\0

How to reproduce it (as minimally and precisely as possible):

new x = !"hello there";

Anything else we need to know?:

This would be a breaking change. It would also affect the {n} packed-array indexing code since it would have to be updated to iterate characters in the correct order, and so packed arrays would also have their order changed. If this repo does move towards supporting an updated VM as well as compiler, this can be solved with an altered version header. If it doesn't, there's not a lot that can be done, since natives would also be broken by this (but also vastly improved, since C code could now read strings directly instead of slowly copying while demangling them).

Environment:

• Operating System

Any

• Compiler version

Any

• How are you invoking the compiler? Pawno, Sublime, vscode, sampctl or command-line?

Any

• If using sampctl, the version number

Any

[IS4Code]

This makes sense if the API requires packed strings, but this ordering is there to differentiate between packed and unpacked strings by the API. If a function expected a packed string, let's say !"Hi!" (48 69 21 00 with your proposal), what if you passed an unpacked "Hi!" instead? The function would interpret it as "H" only, since it sees 48 00 00 00 69 00 00 00etc. Standard AMX API is made to be able to recognize both packed and unpacked strings and treat them equally. With this change, native functions would have to be packedness-aware.

[Y-Less]

Unpacked strings wouldn't change byte order.

[IS4Code]

And? "Hi!", expressed as an array of bytes, is 48 00 00 00 69 00 00 00 21 00 00 00. If you expect a packed string, you will find 48 followed by a terminating null character.

[Y-Less]

Ahh yes, I mixed up the order of bytes in little-endian.