Hi Peter, On Sun, May 5, 2013 at 9:41 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 5 May 2013 11:53, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: >> On Sun, May 5, 2013 at 8:47 PM, Peter Maydell <peter.mayd...@linaro.org> >> wrote: >>> On 5 May 2013 04:58, Jean-Christophe DUBOIS <j...@tribudubois.net> wrote: >>>> no extract16() macro spotted. >>>> Should one be added? >>> >>> There's no need for one -- just use extract32. The only >>> reason for having a separate extract64 is to avoid doing >>> 64 bit arithmetic when we don't have to, I think. >>> >> >> perhaps a quick: >> >> #define extract16(a, b, c) (uint16_t)extract32((uint16_t)(a), (b), (c)) >> >> would keep the 16bit device code explicit and clean? Save on >> dummy casts in certain situations as well (but not this one). > > Hmm, what situations would ever require a cast of the result > or the input of extract32? >
The one off the top of my head: fprintf(stderr, "your 16 field is :%" PRIx16 "\n", extract16(foo, bar, baz)); Otherwise you would have to match PRIx32 to extract 16 which is clumsy. But aren't there there some other varargs situations that may require casts as well? As for the input cast, I got nothin, I just put it in there for completeness. Meet you half way and drop the input cast and keep the output? Regards, Peter > -- PMM >
