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). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60719/new/ https://reviews.llvm.org/D60719 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
