>>> On 15.05.17 at 12:08, <jbeul...@suse.com> wrote: >>>> On 12.05.17 at 19:35, <andrew.coop...@citrix.com> wrote: >> --- a/xen/include/asm-x86/string.h >> +++ b/xen/include/asm-x86/string.h >> @@ -2,13 +2,23 @@ >> #define __X86_STRING_H__ >> >> #define __HAVE_ARCH_MEMCPY >> -#define memcpy(t,f,n) (__builtin_memcpy((t),(f),(n))) >> +void *memcpy(void *dest, const void *src, size_t n); >> +#define memcpy(d, s, n) __builtin_memcpy(d, s, n) >> >> -/* Some versions of gcc don't have this builtin. It's non-critical anyway. > */ >> #define __HAVE_ARCH_MEMMOVE >> -extern void *memmove(void *dest, const void *src, size_t n); >> +void *memmove(void *dest, const void *src, size_t n); >> +#define memmove(d, s, n) __builtin_memmove(d, s, n) >> >> #define __HAVE_ARCH_MEMSET >> -#define memset(s,c,n) (__builtin_memset((s),(c),(n))) >> +void *memset(void *dest, int c, size_t n); >> +#define memset(s, c, n) __builtin_memset(s, c, n) > > Now that xen/string.h has the exact same declarations and > definitions already, why don't you simply delete the overrides > from here?
Hmm, wait - I guess you need to keep them because of the custom implementation. That's awkward, there shouldn't be a need to have redundant declarations just because there are custom implementations. How about making __HAVE_ARCH_* serve both purposes, by allowing it to have different values (besides being defined or undefined)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
