Re: UNALIGNED_MEMCPY

[Guy Harris <gharris () sonic net>]

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.

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.)

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.)
_______________________________________________
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