Hi,
You are right: with 0x1_00_00 we ensure that we fail at the right boundary and
not at something bigger than 0xFF_FF.
I’ll fix that.
Thanks, Sebastian
> Am 22.02.2018 um 12:06 schrieb Justin Mclean :
>
> Hi,
>
>> I extended the test with duplicated hex variants to better visualize the
>
Hi,
> I extended the test with duplicated hex variants to better visualize the
> boundaries:
> @Test
> public void checkUnsignedBoundsLongHex() {
>// Hex representation to visualize valid bounds in bytes
>ByteValue.checkUnsignedBounds(0x0_00_00, 2);
>ByteValue.checkUnsignedBounds(0x0_
Hi,
I extended the test with duplicated hex variants to better visualize the
boundaries:
@Test
public void checkUnsignedBoundsLongHex() {
// Hex representation to visualize valid bounds in bytes
ByteValue.checkUnsignedBounds(0x0_00_00, 2);
ByteValue.checkUnsignedBounds(0x0_FF_FF, 2);
Hi,
> Ok ... if the max value is outside the bounds and the code should have thrown
> an error, then I apologize.
No issue. Looking again at it I’m still not sure which bit or code or test is
wrong or perhaps neither(?) but I think it should be consistent. Perhaps
Sebastian has a better idea?
I take a look at it.
Regarding breaking build: somehow our pipeline implementation handles a test
fail a failure rather than unstable.
So from my POV it would be a +1 on fixing obvious small bugs as soon as you
find them, but when we find a bug with a test that we can’t immediately fix I
think
Hi Justin.
Ok ... if the max value is outside the bounds and the code should have thrown
an error, then I apologize.
I just saw that the value being passed in was the same as the max allowed upper
bound and thought the test was wrong.
Sorry for double breaking __
Maybe Sebastian can have a loo
Hi,
Perhaps my email wasn’t clear. The error is not in the test the error is in the
code the test was showing that. :-)
Thanks,
Justin
> On 22 Feb 2018, at 1:55 am, cd...@apache.org wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> cdutz pushed a commit to bra
