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

Authored by markj on Mon, Aug 10, 7:14 PM.

Details

Reviewers

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 created this revision.Mon, Aug 10, 7:14 PM

Herald added a subscriber: imp. · View Herald TranscriptMon, Aug 10, 7:14 PM

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

Harbormaster completed remote builds in B75499: Diff 183818.Mon, Aug 10, 7:14 PM

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

Herald added a reviewer: scheduler. · View Herald TranscriptThu, Aug 20, 8:04 PM

lwhsu removed a reviewer: scheduler.Thu, Aug 20, 8:13 PM

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