UNALIGNED_MEMCPY

[enh via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: enh <enh () google com>
>
> Date: Wed, 13 May 2026 16:10:45 -0400
>
> the current out-of-line UNALIGNED_MEMCPY() function-like macro means
> that _FORTIFY_SOURCE (or Apple's llvm bounds checking stuff, if you're
> on macOS/iOS) is effectively disabled because the compiler can't "see
> through" the wrapper.
>
> i notice that https://github.com/the-tcpdump-group/tcpdump/commit/2b9bfa05b690f71d08243a8089d6feacbe52b2d2
> took this from being something checked by configure (because, as the
> commit message says, getting that to work with cross compilation is
> very difficult), but it seems to me that the current opt-in to "just
> use the system functions" is the wrong way round? especially in 2026
> it seems like we're better off trying to enumerate any architectures
> that _do_ need this hack, rather than list every single architecture
> that doesn't. (and "especially especially" because all arm variants
> are in the "misalignment is fine" group.)
>
> practically, this means that recent architectures like risc-v and
> loongson aren't in the list. but rather than just add them, it seems
> to me that we should just switch this to m68k-specific check that's
> currently hidden in the #if? flipping it will break sparc, but i
> expect, but if anyone still cares it'll be easier and clearer to add
> that than to keep [forgetting to] curate a long list of architectures
> that "just work"?
>
> happy to send a patch, but i thought this might be contentious...
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s