How do I resolve the warning "Casting to a different object pointer type?"

I can't imagine the scene for what purpose it is necessary to process it, but I remember using a common body when I handled flags in the past.I'm sorry if I took it off.

If you write using a common body,

typedefunion{
    unsigned long_val;
    unsigned char_array[8];
} MYDATA;
:
MYDATA data1 = {0};
MYDATA data2 = {0};

unsigned long_val = 0;
:
(Something to be dealt with)
:
data1.long_val = long_val & data2.long_val;

It's like this.I don't know what will happen if I apply QAC, but I think it will work as long as there is no cast.

I want to resolve the alert without any problems

Rather than that, I think it's better to make the source code readable.

*(unsigned long*) char_array1 = long_val&*(unsigned long*) char_array2

The processing of parts of the differs on x86 series and 68000 series CPUs.
This is because the order in which long is stored in memory is different.

Also, the array of chars has 8 characters (8 bytes), but
*(unsigned long*) copies only the first four bytes of the region.

If you force a char type to cast long, it is very dangerous and cautionary. They told me, so I can clarify it as a design and correct any errors.
If there is no problem, you should take measures to suppress the warning.

However, I am not familiar with the QAC product, so I don't know how to suppress the warning.

Rewrite straightforwardly

 unsigned long_val2=(char_array2[0]&0xff)|
        ((char_array2[1]&0xff)<<8)|
        ((char_array2[2]&0xff)<<16)|
        ((char_array2[3]&0xff)<<24);

    long_val2 = long_val&long_val2;

    char_array1[0]=(long_val2)&0xff;
    char_array1[1] = (long_val2>>8)&0xff;
    char_array1[2] = (long_val2>>16)&0xff;
    char_array1[3]=(long_val2>>24)&0xff;

is the case.(For x86 series CPUs)

Well, if you write like this, the error disappears, and there is no difference in behavior due to differences in CPU.

I need to check the specifications to see if this is the intended result...

Oira would like to vote for the common body, but she has already received a good answer, so another proposal

There is a high possibility that char_array1[8]; is incorrect in the first place.

unsigned long data1,data2;
unsigned long_val;
data1 = long_val & data2;

There are suspicions that is sufficient.This ensures that unsigned long is not wasted on 4-byte processing systems or 8-byte processing systems, and is a strict match. QAC won't complain.

Presentation code is

• unsigned long is (well, normal) alignment4, whereas
• unsigned char is alignment1 and may be placed at odd addresses

Therefore, if a colleague of Oira writes this code, I will point out the following in the review and correct it.

• Show codes are not guaranteed to work on SH2 CPUs (bus error occurred)
• x86 may also incur execution performance penalties for boundary matching violations

Well, how to fix it specifically depends on the original purpose of the code, so I can't judge even if only a piece of code is shown.If it is part of the byte column of the communication telegram, it fails in that it relies heavily on Endianess.