I see this error on travis:

$ python3 ../misra.py -verify misra/misra-test.c.dump

Checking misra/misra-test.c.dump, config ...

Expected but not seen: 244:7.2

Not expected: 506:12.2

Not expected: 662:12.4

Not expected: 664:12.4

The command "python3 ../misra.py -verify misra/misra-test.c.dump" exited with 1.

What does that mean? Also the scriptcheck stage fails, but there is no errors in the output.

What does that mean?

is there unsigned integer overflow or a weird looking shift operation (that would overflow without integer promotion).

is there unsigned integer overflow or a weird looking shift operation (that would overflow without integer promotion).

No I check that before doing a bitshift calculation here.

hmm.. I try..

Example code:

int x = 0u - 1u;

debug output before your changes:

  = always -1
  0u always 0
  - always 18446744073709551615
  1u always 1

debug output after your changes:

  = always !<=-1
  0u always 0
  - always !<=18446744073709551615
  1u always 1

Spontanously it seems to me those values should be known?

The addons did not handle impossible values very nicely. I made a tweak for that with 22727ee

Spontanously it seems to me those values should be known?

They're not set since it can't be stored as MathLib::bigint(see here). The problem is that we set impossible values to -1 because its impossible for the value to be -1 because its unsigned. However, this can lead to confusion if we also interpret -1 as (MathLib::biguint)-1.

To avoid confusion, I skip setting a value if its negative and unsigned unless its an impossible value. If we move to making MathLib::bigint in the future to use arbirtary-precision integer or 128-bit integer, then large unsigned values should not be affected.

The addons did not handle impossible values very nicely. I made a tweak for that with 22727ee

Ok with that fix it still errors with this:

$ python3 ../misra.py -verify misra/misra-test.c.dump

Checking misra/misra-test.c.dump, config ...

Expected but not seen: 244:7.2

Expected but not seen: 737:12.4

Expected but not seen: 738:12.4

I assume there is some misra tests I need to disable. Or perhaps there is some better logic to use to allow for negative values, but I am not sure how.

Ideally the value of the - should be always 0xffffffff. And the value of the = should be always -1.

I assume there is some misra tests I need to disable.

well we could disable those but then we have regressions. It should be detected that 0u - 1u overflows.

Ideally the value of the - should be always 0xffffffff. And the value of the = should be always -1.

I see, this is a 32-bit unsigned integer. This should be fine since we truncate the value, I just need to check the size of the type. Although, it will still be somewhat ambigious with if(x == -1) return; since we dont truncate impossible values.

Of course, this wont fix the issue with -1 and 64-bit integers. For now, we can't represent 18446744073709551615 using a 64-bit signed integer. Even though, 18446744073709551615 should be represented as 0xffffffffffffffff, the problem is that this can be interpreted as either 18446744073709551615 or -1. And there are some places that we will interpret it as -1. We can fix that issue by switching to use a 128-bit integer for MathLib::bigint.

The misra addon needs to be rewritten a bit also. It does not check for overflows properly. If you fix the ValueFlow so the value is correct (0xffffffff) then the addon will not detect the overflow anymore.

We can fix that issue by switching to use a 128-bit integer for MathLib::bigint.

yes. @IOBYTE had such work in progress. how is the progress on that? did that work in windows also or was it only for gcc?

I am guessing that it is not necessary to use 128-bit integers we could use 64 bits for the integer data and then add a flag or something that indicates the sign. I don't know if we could encapsulate such 64 bit value somehow.. so it will be somewhat straightforward to use. For instance if it has internal knowledge about ValueType it could ensure that the value is truncated according to the type and perform the proper integer operations.

yes. @IOBYTE had such work in progress. how is the progress on that? did that work in windows also or was it only for gcc?

I had it working with gcc. I tried a few 128 bit libraries but they all had issues. Some of the removal of bigint patches were merged but bigint is still being used everywhere inappropriately. This is on hold because I'm trying to get simplifyUsing stable for release.

well we could disable those but then we have regressions. It should be detected that 0u - 1u overflows.

I think we should disable the check because it is not implemented properly. And then we should implement the check properly.

So I believe you can ignore that particular problem.

we could use 64 bits for the integer data and then add a flag or something that indicates the sign.

We could build a simple wrapper class that has:

struct bigint {
    biguint data;
    int8_t sign; // Either 1 or -1
};

Implementing the arithmetic operators should be simpler than implementing large integer math. The only thing is that this won't use twos complement.

I had it working with gcc. I tried a few 128 bit libraries but they all had issues.

What were some of the issues? I wonder if we need to write a wrapper around these classes.

I think we should disable the check because it is not implemented properly. And then we should implement the check properly.

It still fails in the CI.

We could build a simple wrapper class that has:

yes exactly. Unless the 128-bit integer works well I think that is a good solution..

It still fails in the CI.

Example code:

unsigned long long k = 0x8000000000000000; // 7.2

with HEAD Cppcheck says the value is a large positive value both in the debug output and dump output. After your changes this value is removed. This particular behavior is unfortunate we have the proper behavior in HEAD as far as I see but not after your changes..

You could add a TODO in the misra-test.c on the corresponding line.

unsigned long long k = 0x8000000000000000; // TODO 7.2

When the ValueFlow is fixed later the verification would fail on this line and then we can remove the TODO.

So sciptcheck fails, but there is no error message.

So sciptcheck fails, but there is no error message.

maybe some test problem.. I restarted that test.

From what I see the Makefile should be re-generated and updated.

It looks like this passes the CI now.