On Fri, May 19, 2017 at 11:09 AM, Robin Dapp <rd...@linux.vnet.ibm.com> wrote: >> I can guess what is happening here. It's a 40 bits unsigned long long >> field, (s.b-8) will be like: >> _1 = s.b >> _2 = _1 + 0xfffffffff8 >> Also get_range_info returns value range [0, 0xFFFFFFFFFF] for _1. >> You'd need to check if _1(with range [0, 0xFFFFFFFFFF]) + 0xfffffffff8 >> overflows against precision of the bit-field which is 40 bits >> precision. The failure might because overflowness is checked against >> unsigned long long's precision which is 64 bits. > >>> Also, is there a possibility to know if there was an "ok" overflow or >>> not from get_range_info ()'s output? Would I have to compare the result >>> with the involved variable's range? >> I think you have to check it manually against max/min value of that >> type precision. > > Currently, extract_... () does that all that for me, is it really too > expensive to call? I guess, using get_range_info first and calling > extract when get_range_info returns a VR_RANGE is not really a favorable > thing to do either? :) Not only the cost, we should avoid introducing more interfaces while old ones can do the work. Anyway, it's Richard's call here.
Thanks, bin > > Regards > Robin >
