4 ms·

Cross-platform code - Is your int still 16 bits on your new CPU? Of course you know* your variable is always between 0 and 15, but the MISRA checker might not**

Cross-platform code - Is your int still 16 bits on your new CPU? Of course you know* your variable is always between 0 and 15, but the MISRA checker might not**. Today we have int16_t et al., so this is much less of an issue. *) IME "know" is often merely a "believe". **) Not sure that even if you have a MISRA checker that has a suitable inference, it is allowed to discard alarms on this kind of violation. I wrote MISRA test cases for something for a suitable powerful checker/analyzer, but I can't remember this detail anymore.

usrnm 3y ago
Why do you think that believing that sizeof(int) == 4 is worse than believing that int32_t exists? It doesn't have to
- ska 3y ago
  If a type doesn't exist in your toolchain, your compile will fail an you will know why. Conversely, incorrect assumptions about size/size/capacity can lead to subtle run-time bugs.
- deleted 3y ago
  [deleted]
- archi42 3y ago
  You have to check sizeof(int) somewhere. Why not do that in a header? To make sure you're using the checked int, define a new type, eg "int4" in that header, too, and use that. Congratulations, you'll fulfill this MISRA rule :) Or just use int32_t and let the compiler fail if your Toolchain does not have that. Then just write an appropriate header to add it (with the correct checks) ;)
astrange 3y ago
If you know your variable is between 0 and 15 and care deeply about this, I kinda think you should get explicitly-ranged integer types added to your language rather than use a type that's defined for -32767 - 32767 but doesn't enforce it. Also, IME it obscures bugs in your code if you're forced to overspecify things, because now someone reading it has to determine if all those explicitly specified details are actually correct or not.
- IshKebab 3y ago
  Definitely! But MISRA is about writing robust code with an error-prone language, not picking a different language that is better designed. Your second point doesn't make any sense. Someone reading `int` has to determine if that is actually correct or not too.
  - astrange 3y ago
    > Your second point doesn't make any sense. Someone reading `int` has to determine if that is actually correct or not too. If you assign an int32_t to an int16_t because you know the actual range of values fits at that point, later readers don't necessarily know that. (And it can change.) If they're both int, there's no possible problem.
    - IshKebab 3y ago
      You're suggesting using the same integer type everywhere. If so you can use `uint64_t`. To put it another way: > If they're both int32_t, there's no possible problem.
- archi42 3y ago
  I agree, and there is tooling to do this kind of thing with C/C++. If this was embedded into the language, you'll quickly learn that static checking has its limits; dynamic checking introduces a new class of failure mode into your embedded, safety critical (as in kills or destroys) system, which might also not be what you want. It's a conundrum :( The second statement contradicts the first - int16_t is too specific and hides errors, but an arbitrary range is not?
  - astrange 3y ago
    > The second statement contradicts the first - int16_t is too specific and hides errors, but an arbitrary range is not? The arbitrary range is actually capable of being correct. int16_t is almost never "correct", since it's larger than the actual range of values. It can also be said to be an over-optimization, since on some platforms like x86 it's easier to deal with 32-bit values than 16-bit ones.

usrnm 3y ago

Why do you think that believing that sizeof(int) == 4 is worse than believing that int32_t exists? It doesn't have to

ska 3y ago
If a type doesn't exist in your toolchain, your compile will fail an you will know why. Conversely, incorrect assumptions about size/size/capacity can lead to subtle run-time bugs.
deleted 3y ago
[deleted]
archi42 3y ago
You have to check sizeof(int) somewhere. Why not do that in a header? To make sure you're using the checked int, define a new type, eg "int4" in that header, too, and use that. Congratulations, you'll fulfill this MISRA rule :) Or just use int32_t and let the compiler fail if your Toolchain does not have that. Then just write an appropriate header to add it (with the correct checks) ;)

astrange 3y ago

If you know your variable is between 0 and 15 and care deeply about this, I kinda think you should get explicitly-ranged integer types added to your language rather than use a type that's defined for -32767 - 32767 but doesn't enforce it. Also, IME it obscures bugs in your code if you're forced to overspecify things, because now someone reading it has to determine if all those explicitly specified details are actually correct or not.

IshKebab 3y ago
Definitely! But MISRA is about writing robust code with an error-prone language, not picking a different language that is better designed. Your second point doesn't make any sense. Someone reading `int` has to determine if that is actually correct or not too.
- astrange 3y ago
  > Your second point doesn't make any sense. Someone reading `int` has to determine if that is actually correct or not too. If you assign an int32_t to an int16_t because you know the actual range of values fits at that point, later readers don't necessarily know that. (And it can change.) If they're both int, there's no possible problem.
  - IshKebab 3y ago
    You're suggesting using the same integer type everywhere. If so you can use `uint64_t`. To put it another way: > If they're both int32_t, there's no possible problem.
archi42 3y ago
I agree, and there is tooling to do this kind of thing with C/C++. If this was embedded into the language, you'll quickly learn that static checking has its limits; dynamic checking introduces a new class of failure mode into your embedded, safety critical (as in kills or destroys) system, which might also not be what you want. It's a conundrum :( The second statement contradicts the first - int16_t is too specific and hides errors, but an arbitrary range is not?
- astrange 3y ago
  > The second statement contradicts the first - int16_t is too specific and hides errors, but an arbitrary range is not? The arbitrary range is actually capable of being correct. int16_t is almost never "correct", since it's larger than the actual range of values. It can also be said to be an over-optimization, since on some platforms like x86 it's easier to deal with 32-bit values than 16-bit ones.