Re: UNALIGNED_MEMCPY

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

> --- Begin Message ---
>
>
> From: enh <enh () google com>
>
> Date: Thu, 14 May 2026 16:52:32 -0400
>
> On Wed, May 13, 2026 at 6:59 PM Guy Harris <gharris () sonic net> wrote:
> > On May 13, 2026, at 1:10 PM, enh via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
> >
> > > 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.
> >
> > Yes, the point was to keep the compiler from "helpfully" seeing through the wrapper and "helpfully" assuming 
> > alignment.
> >
> > > 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
> >
> > Then the right thing to do is to switch to a check for the processors that *don't* handle unaligned loads, which 
> > would be the 68000, the 68010/68012, and SPARC.
>
> yeah, that would be my suggestion.
>
> > I'm not sure about 32-bit Arm, though. It may be that the 32-bit Arm platforms that matter do handle unaligned loads. 
> > (No need to worry about people running Unix-like systems on the System/360 Model 67, although an early Unix port to 
> > S/3x0 was done atop TSS, which was originally developed for the Model 67.)
>
> 32-bit arm currently assumes that unaligned loads are fine, so this
> wouldn't be a regression. (and even there, arm32 linux has
> https://www.kernel.org/doc/Documentation/arm/mem_alignment so it's
> possible people aren't hitting this in practice, even if they are
> running on pre-armv6 hardware in 2026.)
>
> > This all applies to UNALIGNED_MEMCMP() as well.
> >
> > (If there's a better way to prevent the compiler from "helpfully" incorrectly assuming alignment, that'd be great, 
> > but introducing the nd_ "this is just a bag of N bytes" types wasn't, as I remember, sufficient for some stubborn 
> > compilers.)
>
> do you actually have a broken memcpy()/memcmpy() in mind? they're
> specified to work on "characters" despite the void*, and even in my
> armv5 days the usual fix for unaligned accesses was to _switch_ to
> memcpy(). from the git history it seems like the calls (certainly from
> 2010 on) were added "by analogy" rather than because of a known need?
>
> the other alternative that occurred to me (if we think this is
> actually needed at all, which i'm increasingly less certain of) is
> adding a configure option, so anyone who does have this problem can
> opt-in manually regardless of cpu architecture...
>
> --- 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