zpl

It looks like ZPL has its own memcpy() implementation which is a work in progress. https://github.com/zpl-c/zpl/blob/dfcb9538967f381363eaef10f9... That leads me to believe feedback is desired so assuming the author posted this as a Show HN kind of thread, here's some of what I've learned implementing that function. It goes pretty quick on the machines I've used so far to have an indirect branch with overlapping moves. Here's what that looks like in "pure c" for gcc and clang. https://github.com/jart/cosmopolitan/blob/master/libc/str/me... memcpy is hard to implement in pure c99 because aliasing pointers to non-char types can trigger ubsan errors. With rep movsb it's a good idea to check cpuid for erms support. In that case it'll be fastest for bigger moves but is still slower for small moves. See the chart at https://justine.lol/cosmopoli

The zpl_u64 seems to be because they're trying to support older versions of the MSVC compiler[1]. As for why they're using a signed size parameter, I'm not really sure. One idiom they appear to use often is[2]: for (...; x--; y++) where x is a size-type of some kind. They may be defaulting to signed size types to avoid errors in case somebody decides to change to above to: for (...; x-- >= 0; y++) There's even a macro zpl_size_of: #define zpl_size_of(x) (zpl_isize)(sizeof(x)) But the real weirdness is in the other macros: #define cast(Type) (Type) ...just why? And #define ZPL_MULTILINE(...) #__VA_ARGS__ is supposed to be a way of having multiline literals in C. But, everything inside the "..." has to be valid C tokens. It might work as a string literal in many cases, but it's misleading at best and broken at worst