HEX-ENCODE HEX-DECODE and BASE64-ENCODE are not CPU endian-ness aware

When BASE64-ENCODE or HEX-ENCODE and HEX-DECODE functions are used where the data will be moved between computers where the endian-ness of the CPUs differs, the results will not be what is expected because the data will be interpreted in a different byte order.

The value 0x0000011 to returns 285212672 rather than 17

This is expected behavior when handling endian aligned values between distributed systems.  A Documentation Defect has been raised to make clear that HEX-ENCODE and HEX-DECODE functions do not take into account CPU endian-ness when doing their work. 

Hex-binary and BASE64-ENCODE functions are expected to accurately transfer, byte for byte, an array of bytes between any two platforms regardless of the hardware's endian alignment.

When the sender of a byte array inserts endian aligned data values, they are responsible for endian aligning the value to a specific type and publishing that alignment type so the receiver can extract the endian aligned data value from the array and realign it for their hardware.

OpenEdge HEX and BASE64 encoding and SET-BYTE-ORDER functions support all of the above for both transmitting and receiving.

 

When using BASE64 encoding or HEX-ENCODE and HEX-DECODE functions on systems where the CPU endian-ness is not the same, ensure that both sides of the application use the SET-BYTE-ORDER function when building the data so that the byte order of the MEMPTR variables is the same between the platforms:

• HEX and BASE64 encoding does not do any byte-ordering. The code simply goes byte-by-byte starting at the first byte in the RAW value passed so the result will be dependent on the machine's endianness
• SET-BYTE-ORDER puts the values in the RAW value in the byte order required.

References to Other Documentation: 

OpenEdge Development: Programming Interfaces, Using MEMPTR to reference external data, Setting byte order