[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/3] x86/string: Clean up x86/string.h
On 15/05/17 11:19, Jan Beulich wrote: > >>> On 15.05.17 at 12:08, <JBeulich@xxxxxxxx> wrote: >>>>> On 12.05.17 at 19:35, <andrew.cooper3@xxxxxxxxxx> 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)? I don't understand how you would intend this new __HAVE_ARCH_* to work. ARM uses the current behaviour to implement memset() as a local macro. Given that these files aren't likely to change much at all, I'd recommend keeping the same behaviour as Linux. It is only 3 lines after all. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |