[PATCH] D60719: Demonstrate how to fix freestanding for memcpy

Tim Northover via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 17 11:42:25 PDT 2019

t.p.northover added a comment.

> IIUC freestanding environment should not rely on memcpy being present so my take on it was that by "fixing" freestanding I could have my cake and eat it too.

The formal situation is that freestanding implementations are only required to provide language support stuff like `va_list`. They're allowed to give more of the standard library if they want though, as implementation defined behaviour.

In practice, everyone I know provides the basic `string.h` functions and the compiler is pretty explicit about relying on them being present for correctness. They're part of the surrounding environment a user is expected to supply (much like the various exception handling callbacks if you want C++ exceptions, but always required).

For the people actually using freestanding I think they're mostly considered important enough that they're implemented in assembly anyway so this isn't really a burden, but...

> Ultimately I'm interested in implementing libc's mem function in C++. Let's take memcpy for instance

Ah, that is an entirely different problem from what I thought you were trying to do. In that case I'm all in favour of some solution, but would start thinking along the lines of `-fno-builtin-memcpy` options (it's possible that already does what you want, but can't get LLVM to form a `memcpy` from quick tests to check).

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list