On Fri, May 30, 2014 at 1:02 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 05/30/2014 08:48 AM, Andy Lutomirski wrote: >> This adds a macro GET(x) to convert x from big-endian to >> little-endian. Hopefully I put it everywhere it needs to go and got >> all the cases needed for everyone's linux/elf.h. >> >> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx> >> --- >> arch/x86/vdso/vdso2c.c | 15 ++++++++++++ >> arch/x86/vdso/vdso2c.h | 63 ++++++++++++++++++++++++++++---------------------- >> 2 files changed, 50 insertions(+), 28 deletions(-) > > A couple of observations: > > 1. We shouldn't use double-underscore in host C code. > > 2. It would be nice if we can take these sort of things (host-build > helper macros) and move them to some common file in the Linux kernel > eventually, so it would be a good thing to make the naming a little > less general. > > 3. Even though it isn't necessary, making it work on 8-bit values so > one doesn't have to worry about the type would seem like a good > thing. > > I came up with the following, it seems like a reasonable simplification: > >> #define _LE(x, bits, ifnot) \ >> __builtin_choose_expr( \ >> (sizeof(x) == bits/8), \ >> (__typeof__(x))le##bits##toh(x), ifnot) This will do awful things if x is a floating-point type, and, for integers, the cast is probably unnecessary. But it should be okay. >> >> extern void bad_le(uint64_t); If this ever goes in a common header, then we should do the __attribute__((error)) thing. I wonder if it would ever make sense to have __LINUX_HOSTPROG__ and make some of the basic headers work. Hmm. >> #define _LAST_LE(x) \ >> __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) >> >> #define LE(x) \ >> _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x)))) > > What do you think? My only real real objection is that _LE sounds like converting *to* little-endian to me. Admittedly, that's the same thing on any remotely sane architecture, but still. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
