A couple of questions for people who know low-level things: * Of Debian's architectures (official and otherwise), which ones are known/defined/designed to be OK with unaligned accesses from user-space, and which ones (can be configured to) crash or give wrong answers?
* Would it be safer to assume that future architectures are in the "unaligned accesses are OK" category, or the "not OK" category? The ones I know for sure are: - OK: any-i386, any-amd64 - not OK: armel I believe powerpc, s390 and arm64 might be in the "OK" category, and mips* and sparc in the "not OK" category. I've seen conflicting information about which category armhf is in: on #757037, Marc Kleine-Budde said that ARMv6 and up guarantee that unaligned access is fine, but I've also found Ubuntu bug reports about unaligned access failures on armhf. The context is that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037 describes lzo2 failing to start up on armel due to unaligned memory accesses. lzo2 has a cpp macro, LZO_CFG_NO_UNALIGNED which can be defined to stop it doing "clever" things with casting pointers. If the maintainer doesn't object (or fix the bug of course), I intend to NMU lzo2 to use that macro on at least armel; I would like to sanity-check whether I should be using a blacklist or whitelist approach, and which architectures other than armel should be on the blacklist, or which architectures other than x86 should be on the whitelist. Relatedly, if we have typedef struct lzo_memops_TU2_struct { unsigned char a[2]; } lzo_memops_TU2; *(lzo_memops_TU2 *) (void *) dest = *(const lzo_memops_TU2 *) (void *) src; is gcc within its rights to optimize that into an aligned 16-bit load and an aligned 16-bit store, even though alignof(lzo_memops_TU2) == 1; or should gcc be emitting pessimistic byte-by-byte code for that? (Unfortunately this is itself a slight simplification, because this part of lzo2 is a maze of twisty typedefs all different.) Thanks, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546f333a.9050...@debian.org