On 05/05/2013 01:53 PM, Peter Crosthwaite wrote:
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
I will use extract32() for now.
JC
-- PMM
