Summary

ffBase64EncodeRaw() unconditionally byte-swaps the input word with __builtin_bswap32(), which only yields the intended big-endian byte layout on little-endian hosts. On big-endian hosts the 32-bit load is already in the correct order, so the swap reorders the bytes within every 3-byte group and emits corrupted base64.

All currently tested platforms (x86-64, aarch64) are little-endian, so the bug is latent there. I hit it while porting fastfetch to the NetBSD/amiga (Motorola 68k) target. ffBase64EncodeStrbuf() is used only in the image-logo path (src/logo/image/image.c): the iTerm inline-image protocol (which encodes the image bytes) and the kitty-direct protocol (which encodes the image path). So on a big-endian machine, image logos are transmitted as malformed base64 and fail to render; text/ASCII logos, info modules and --format json are unaffected.

The fix simply guards the swap so it only runs on little-endian hosts, leaving little-endian output byte-for-byte unchanged.

Testing

• Big-endian (Commodore Amiga 1200, 68060, NetBSD): running the actual --logo-type iterm path on a 150-byte file, the current code emits base64 that neither matches base64(1) nor decodes back to the original bytes; the patched build emits base64 identical to the reference that decodes back correctly.
• Little-endian (amd64): output is unchanged and remains correct (verified the guarded branch is still taken, producing the same base64 as before).

Related issue

N/A

Changes

• Guard the __builtin_bswap32() in ffBase64EncodeRaw() with __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ so the encoder is correct on both little- and big-endian architectures.

Checklist

• I have tested my changes locally (and on real big-endian m68k hardware).