4 ms·
Arguably the mem*() functions are part of the "useful stdlib core" functions. Also be aware that the standard memcpy() and a handful other C stdlib functions ar
by flohofwoe 4y ago
Arguably the mem*() functions are part of the "useful stdlib core" functions. Also be aware that the standard memcpy() and a handful other C stdlib functions are essentially treated like a builtin by compilers, e.g. the compiler can add or remove memcpy calls as it sees fit.
- mgaunard 4y agoThe mem functions are available as compiler built-ins, no need for libc.
- Karellen 4y agoWell, that depends on your compiler.
- mgaunard 4y agoGCC is the standard.
- Karellen 4y agoHuh. Last time I looked at the standard, I didn't see where that was mentioned. Could you point me at the relevant section, please?
- mgaunard 4y agoYou don't appear to understand what the word standard means.
- beached_whale 4y agoIt's called GNU/C Standard /jk
- flohofwoe 4y agoNot on Windows or Mac.
- mgaunard 4y agoThe platform compiler on Mac is Clang, which is specifically designed to be GCC-compatible, because GCC is the industry standard.
- flohofwoe 4y ago*rolls eyes* 1. There is no "industry standard" for C compilers, for instance in the game dev world, the closest thing to an "industry standard compiler" is MSVC, and not GCC or Clang. 2. While Clang tries to emulate some GCC-isms, it also has important differences to GCC. On Windows, Clang also emulates a lot of MSVC-isms, so emulating GCC really doesn't mean anything.*
- mgaunard 4y agoMicrosoft explicitly considers C legacy, and offer a C++ compiler instead.
- dezgeg 4y agoNo. While the compiler can optimize memcpy calls to direct loads/stores for small arguments (when inlining the loads/stores would be smaller than the cost of calling memcpy), for bigger or not statically know sizes it WILL call to memcpy in libc. And in fact it may even emit memcpy calls for things like struct copies.
- mgaunard 4y agowhether you want the built-in to have the ability to refer to an external definition is a compiler flag.
- wizofaus 4y agoIs there actually an offical list of stdlib functions compilers are "permitted" to inline - and why shouldn't they be able to do it for any such function? If they're statically linked I can't see how it matter, you're just saving on some machine code instructions to push arguments to the stack and pop them off again (plus the instruction pointer jumps) surely?
- flohofwoe 4y agoIt's not just about inlining, the compiler may decide to entirely remove memory accesses when memcpy is used to copy one struct to another, like in this case: https://www.godbolt.org/z/Ezb7hh6eq https://www.godbolt.org/z/Ezb7hh6eq ...and for the same reason, AFAIK the compiler isn't required to preserve struct padding bytes either in such a case, so even though memcpy() is used for copying one struct into another in the original source code, the compiler may actually generate code which behaves differently from a straight memcpy() - but in this case I'm not 100% sure, I just wouldn't depend on it, because I've been bitten in the ass multiple times when it comes to assuming the content of padding bytes.