1

I have test this code and result is correctly, but will got "567 S Pointer arithmetic is not on array." in line24 "arr++;", does anyone know how to fix it?

#include <iostream>

using namespace std;

int PartNum_Read(char* arr);

int PartNum_Read(char* arr)
{
    uint32_t ret = 0U;
    uint8_t ReadPartNumer[3]={'a','b','c'}; //copy from other function, type is uint8_t
    if(arr != NULL)
        {
            for(int j = 0U; j < sizeof(ReadPartNumer); j++)
            {
                *arr = static_cast<char>(ReadPartNumer[j]);
                 arr++;
            }
            ret = (sizeof(ReadPartNumer));
        }
    cout << "PN: " << *arr << endl;
    
    return ret;
}

int main()
{
    cout<<"Hello World\n";
    char PartNumer[3]={0};
    PartNum_Read(&PartNumer[0]);
    for(int i = 0U; i < 3; i++)
    {
        cout << "PN: " << PartNumer[i] << endl;
    }
    return 0;
}
Nick Lee
  • 29
  • 4
  • Don't do pointer arithmetic at all? Use plain array indexing? Like `arr[j] = ...`? – Some programmer dude Jul 07 '23 at 08:55
  • 1
    Instead of using "C" style arrays (and poiner decay). Consider using std::array, or std::vector. Now you main and you read function are 'in sync' because both by accident use an array of size 3, but with "C" style arrays that is too easy to break and result in bugs. std::array & std::vector always carry their own size with them. – Pepijn Kramer Jul 07 '23 at 09:03
  • 2
    May I ask where you are learning C++ from? (Because the source seems to be teaching an almost archaic style of C++, that's more like "C") – Pepijn Kramer Jul 07 '23 at 09:04
  • Could you please express in plain english what `PartNum_Read` is supposed to do? – Bob__ Jul 07 '23 at 09:28
  • @PepijnKramer Safety-related applications do not allow "experimental" new features of C++ from C++11 or later. Or arguably the C++ language in the first place. The main reason why is that the list of all poorly-defined behavior in C++ is so complex that C++ gurus are still struggling with writing one (we're talking about a tome of 1000+ pages where each line is a brief summary of something poorly defined). There was a guy working on it but I'm not sure if it ever made it to publication, I think he was struggling to keep up with all the new poorly-defined behavior added with each C++ release. – Lundin Jul 07 '23 at 10:43
  • (Found it: seems to be [ISO WG23](https://www.open-std.org/jtc1/sc22/wg23/docs/documents) as well as SG12 below WG21 (C++). They have a whole working group of some >10 people, it seems.) – Lundin Jul 07 '23 at 10:52
  • @Lundin Well I can imagine that ;) Even after working with C++ for close to 30 years I cannot for the live of me guarantee I will not have some UB somewhere (and just have to rely on unit tests). And I didn't know MISRA was that far behind to be honest. It kind of explains the archaic look of OP's code though ;) – Pepijn Kramer Jul 07 '23 at 10:58
  • @PepijnKramer It has not been updated since 2008, but MISRA is currently working on an update "MISRA C++:202x". This started last year, something like that. – Lundin Jul 07 '23 at 11:09
  • @PepijnKramer MISRA gets even worse when applied blindly just to satisfy the linter. I'm far from recommending all the newest languages and features but after several years of working with MISRA-compliant code I managed to develop strong opinions on it. And not necessarily the positive ones. – alagner Jul 07 '23 at 13:07
  • 1
    I don't have to use MISRA, I've seen it about 15 years ago (took some hints from it for coding guidelines back then). But the C++11 and later features imo were much better at preventing bugs (in non safety critical system I must add). Adn with any tool that is used to check code quality toolsatisfaction is always a risk. – Pepijn Kramer Jul 07 '23 at 13:20

1 Answers1

1

The older MISRAs like C:2004 and C++:2008 had various confused rules regarding pointer arithmetic. The recommendation is to upgrade to MISRA C:2012 or later.

The "fix" in this case is as stupid as the rule:

int PartNum_Read (char arr[])

Yes, that so-called "fix" doesn't make any difference at all in practice. But it should make the code compliant to MISRA C++:2008.

The root problem here is a failure to understand pointer arithmetic when these guidelines were written. It's a common misconception, as addressed here: Do pointers support "array style indexing"? But these known MISRA problems have been fixed since long, at least on the C side.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Yes, thansk for your reply. Change to array type can fix this case, but show another fail as "Array passed as actual parameter", so confused.... I think we need to upgrade to MISRA 2012 first. – Nick Lee Jul 10 '23 at 00:59