string definition

"If I change
#define A "\xA0\x01\x01"
#define B "\xA0\x02\x02"
it will be OK."

So what exactly is your question?

and what exactly are you trying to achieve?

Tam,

I'm guessing that the debugger is assuming that you want to look at these variables as NULL-terminated strings. This means that it figures anything after the first null (0x00) character is just junk in memory that you don't want to see. They look the same in the first example because they ARE the same up to the first null character. In the second, you got rid of the null, so they appear different. If you look directly at memory, you'll probably see what you expect.

They are both NUL-terminated after '\xA0'.

My problem is following two definitions are the same according to the compiler.

#define A "\xA0\x00\x01"
#define B "\xA0\x00\x02"

  if( memcmp( in_buffer, A, sizeof(A))==0)
  {
    handle_cmd_A();
  }
  else if( memcmp( in_buffer, B, sizeof(B))==0)
  {
    handle_cmd_B();
  }
  else
  {
    ...
  }

"My problem is following two definitions are the same according to the compiler."

No - not according to the Compiler.

What people are talking about is that the way that the Debugger displays the data.

The suggestion is that the Debugger is assuming that your data is supposed to be a null-terminated 'C' string, and so is terminating its display of the string at the first null.

You need to inspect the memory directly to be sure of what's going on.

An alternative might be:

#define HEADER_0 0x0A
#define HEADER_1 0x00

#define MSG_TYPE_1 0x01
#define MSG_TYPE_2 0x02

if( (in_buffer[0]==HEADER_0) && (in_buffer[1]==HEADER_1) )
{
   // We have detected the start of a header
   // Now check which type of message it is

   if( in_buffer[2]==MSG_TYPE_1 )
   {
      // It is a Type-1 message
   }
   else if( in_buffer[2]==MSG_TYPE_2 )
   {
      // It is a Type-2 message
   }
}

The suggestion is that the Debugger is assuming that your data is supposed to be a null-terminated 'C' string, and so is terminating its display of the string at the first null.
You need to inspect the memory directly to be sure of what's going on.


I am sure that it is a compiler problem because I have checked the asm listing that the compiler only generate one constant string.

Besides, the asm listing shows both memcmp() use pointer pointing to the same location in its second parameter.

 if( memcmp( in_buffer, A, sizeof(A))==0)
 {
 }
 else if( memcmp( in_buffer, B, sizeof(B))==0)
 {
 }

"I am sure that it is a compiler problem because I have checked the asm listing that the compiler only generate one constant string."

If these 'arrays of char' are treated as string literals then they are identical up to the nul terminator. So, I guess it may be reasonable for the compiler to disregard the third character and merge the literals. Or, it may be that the compiler is being a bit too clever for its own good in this case.

Yes, I think the compiler is here a little to clever. We will re-work the string merging in the CARM compiler, so that these strings are not identical anymore.

Reinhard