On Tue, Aug 18, 2020 at 12:03 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>
> I'm not saying "change the semantics", nor am I saying that playing
> whack-a-mole *for a limited time* is unreasonable. But I would like to go back
> to the compiler authors and get them to implement such a #pragma: "this
> freestanding implementation *does* support *this specific library function*,
> and you are free to call it."
I'd much rather just see the library functions as builtins that always
do the right thing (with the fallback being "just call the standard
function").
IOW, there's nothing wrong with -ffreestanding if you then also have
__builtin_memcpy() etc, and they do the sane compiler optimizations
for memcpy().
What we want to avoid is the compiler making *assumptions* based on
standard names, because we may implement some of those things
differently.
And honestly, a compiler that uses 'bcmp' is just broken. WTH? It's
the year 2020, we don't use bcmp. It's that simple. Fix your damn
broken compiler and use memcmp. The argument that memcmp is more
expensive than bcmp is garbage legacy thinking from four decades ago.
It's likely the other way around, where people have actually spent
time on memcmp, but not on bcmp.
If somebody really *wants* to use bcmp, give them the "Get off my
lawn" flag, and leave them alone. But never ever should "use bcmp" be
any kind of default behavior. That's some batshit crazy stuff.
Linus
