Page MenuHomeFreeBSD

libc: Avoid defining memcpy() as a macro under FORTIFY_SOURCE
Needs ReviewPublic

Authored by markj on Aug 10 2026, 7:14 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Sep 8, 9:25 PM
Unknown Object (File)
Tue, Sep 8, 3:36 AM
Unknown Object (File)
Mon, Sep 7, 1:04 AM
Unknown Object (File)
Sat, Sep 5, 4:22 PM
Unknown Object (File)
Fri, Sep 4, 4:49 PM
Unknown Object (File)
Fri, Sep 4, 3:36 PM
Unknown Object (File)
Fri, Sep 4, 12:27 PM
Unknown Object (File)
Fri, Sep 4, 9:39 AM
Subscribers

Details

Reviewers
kevans
Summary

Otherwise it is impossible to make certain memcpy() usages work, e.g.,
memcpy(dst, &(struct foo){1, 2}, sizeof(*dst)) fails to compile
because a macro parameter can't contain a comma. This arises when
compiling graphics/mesa-libs with FORTIFY_SOURCE enabled.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 75499
Build 72382: arc lint + arc unit

Event Timeline

markj requested review of this revision.Aug 10 2026, 7:14 PM

@kevans do you have any time to look at this?

It should probably be noted that this effectively orphans the corresponding __*_chk symbols in libc/secure. I don't think that's a bad thing or that we should stop exposing a default version for them, it just means that we won't emit references to them with our own implementation.

include/ssp/string.h
123–126

I think we probably want __ssp_redirect_raw_impl for these two like we do in <ssp/wchar.h>; the easy __ssp_redirect* loses runtime overlap checks for src/dst that are currently done by the __*_chk symbols